OliverCode

Overview

A fix is not considered complete until the original problem no longer reproduces, the regression test passes or the missing test coverage is documented, and temporary debugging instrumentation is removed.

Where a person stays in control

• Reports the symptom, such as "debug this" or "this is slow"
• Supplies access to the reproducing environment, a captured artifact or permission for temporary production instrumentation when the agent cannot build a loop
• Decides on any architectural change the post-mortem recommends

What runs on its own

• Builds and tightens the loop, and runs it before theorizing
• Stops and lists what it tried when no loop can be built, and refuses to hypothesise without one
• Ranks falsifiable hypotheses, instruments one variable at a time and removes every tagged log at the end
• Writes the regression test before the fix where a correct seam exists

Overview

Findings must be supported by evidence from the actual files, and recommendations become tracked issues. The goal is a concrete, prioritized list of improvements that someone can act on.

Where a person stays in control

• Names the target, for example "audit this" inside a repo, a skill family, a docs folder, a commit range or a plan file
• Decides the owner questions the audit files as stories that name what they block

What runs on its own

• Reads every line in scope and checks the seven lenses: how a new user gets it working, whether it runs on its own, whether its claims are true, whether each idea has one home, what it carries that nothing uses, what it costs to load and whether its writing follows the voice
• Reruns the evidence behind the biggest claims before reporting them
• Counts size, tests and doc words with scripts and reports the numbers
• Files every finding as a story with a before-and-after command, and fixes nothing during the audit apart from three stated exceptions

Overview

The skill connects planning, implementation, and backlog maintenance, requiring a logged builder entry before completion. Owner requests that involve meaningful changes are captured before work begins, keeping the backlog useful as a record of what needs doing and what has actually been delivered.

Where a person stays in control

• States the request, and the agent files it
• Says "stop", "do this first" or "drop that" to change the order of work
• Approves any fix the sweep proposes
• Asks for QA when it is wanted

What runs on its own

• Searches before filing and adds duplicates as comments on the existing story
• Writes each story with a user-story sentence, Gherkin acceptance criteria, an epic link and the fields line
• Answers the fit check in the body: what the item extends, whether it is core or an add-on, what it replaces and its effect on size
• Runs the sweep, and reports "Nothing due" when the board is clean or says so plainly when a read was stopped, since a stopped read never counts as clean
• Uses a different agent that built no part of the story for QA, when the owner asks for it

Overview

It first checks the current configuration, separates global, project-specific, and personal instructions, and identifies overlaps. Existing rules are preserved or explicitly flagged, with backups maintained until the owner confirms the migration.

Where a person stays in control

• Agrees to the table that sorts each existing rules file into global, repo-specific or personal
• Confirms which repos are live, which are retired and which should not be governed
• Confirms the validation command proposed for each repo
• Decides when backups can be deleted

What runs on its own

• Reads the documentation so the user does not have to
• Backs up before the first mutation
• Leaves any rule it cannot classify exactly where it is and flags it
• Tells the user two things they rarely know: a rules file named AGENTS.md or .cursorrules never auto-loads in Claude Code, and a real directory in ~/.claude/skills/ has no backup anywhere
• Reports what moved, what stayed, what is ambiguous, the enforcement probe result and where the backups are

Overview

The skill records how much source material it read and makes any remaining assumptions explicit. Plans are saved as reviewable files so they can be approved and tested before implementation begins.

Where a person stays in control

• Asks for a plan with "make a plan", "write this up as a plan first" or "don't start coding yet, just plan"
• Approves the plan before any execution
• Chooses the repo when the work spans several

What runs on its own

• Reads all N items before writing a sentence that claims something across N named items
• Discloses any partial check in the plan, so the audit skill's plan route can test the rest
• Writes the dated file and stops
• Appends findings during execution and keeps the original plan intact

Overview

The skill defines what it will do and who it is for before development begins, then checks that it can operate independently on another machine. Clean-room testing catches missing references, files, or configuration that might otherwise go unnoticed.

Where a person stays in control

• Describes the job in a sentence or two and what a person would say to trigger it
• Shares an example of the input and output wanted, or lists the skills already used for this job
• Approves the four-line target

What runs on its own

• Checks the live fleet for overlap, and does not rely on memory
• Holds the skill to the baseline: no personal facts, no reads outside the skill folder (a skill shipped inside OliverCode may read $OC/ files), a description under 150 words, only three fictional-safe placeholder names (Jane Doe, John Smith, Sally May), and only files the skill uses
• Turns any step a command can do into a script, and gives each script a test that goes red without its guard
• Never finishes with a named gap open