Skill Library Audit

Core Question

Should a proposed or existing skill be added, compacted, merged, split, deferred, or rejected to keep the skill library small, routable, and low-confusion?

When To Use

Use this skill when:

• reviewing a new proposed Git skill
• auditing overlap between existing skills
• deciding whether a workflow should be a first-class skill or a reference
• checking whether a skill over-acts beyond its owner boundary
• checking whether skill growth increases context bloat or routing confusion

When Not To Use

Do not use this skill when:

• executing Git operations
• editing skill files directly
• rewriting a skill after the audit decision
• reviewing project code unrelated to skill library design

Route to:

• implementation work routes to the repository editing workflow
• Git repository state routes to repo-state-diagnosis
• skill execution issues route to the owning skill

Required Evidence

Before action, inspect or establish:

• proposed skill name and core question
• existing skills/routing.md ownership table
• existing SKILL.md boundaries for adjacent skills
• reference/test/changelog footprint
• expected frequency of use
• mutation and tool-use scope
• context budget impact and likely lazy-load triggers

No-evidence rule:

• Do not make strong claims without observed evidence.
• State assumptions when proceeding under incomplete evidence.
• Stop when missing evidence affects safety, correctness, user work, remote state, or irreversible action.

Operating Contract

You MAY:

• inspect relevant repository state and project files.
• generate a plan, report, or local artifact within the declared risk scope.
• route to another skill when the requested action is outside this skill's owner boundary.

You MUST:

• inspect before acting.
• keep the task within the declared owner boundary.
• classify state and risk before any meaningful action.
• preserve unrelated user work.
• verify outcomes proportional to risk.
• report evidence, assumptions, actions, verification, and residual risk.

You MUST NOT:

• invent project policy.
• expose secrets or sensitive values.
• mutate unrelated files or refs.
• perform destructive, remote, shared, history-rewriting, or irreversible actions without explicit action-specific confirmation.
• continue after unexpected destructive output.

State / Risk Table

Workflow

1. Identify the user goal and current owner boundary.
2. Inspect required evidence.
3. Classify repository/task state.
4. Classify risk using the declared scope.
5. Choose the minimal sufficient action or route.
6. Execute only allowed actions, if any.
7. Verify outcome or self-check the artifact.
8. Report result, evidence, verification, assumptions, and residual risk.

Decision Rules

• A first-class skill needs a unique problem class, distinct evidence model, distinct state/risk model, and one-sentence routing condition.
• If a workflow is rare, mostly explanatory, or shares the same state/risk table as an existing skill, keep it as a reference first.
• Reject or defer skills that make the agent more likely to select multiple adjacent skills without a clear primary owner.
• Prefer read-only audit decisions over repository mutation.

Tool Rules

• May read skill files, routing files, README, references, tests, and changelogs.
• May generate an audit report or proposed routing diff as an artifact.
• Must not edit, stage, commit, or push files.
• Must not execute Git mutation commands.

Verification

Minimum verification:

• Check each decision against ownership, overlap, context cost, risk scope, references, tests, and routing impact.
• For Add decisions, verify required supporting layers are specified.
• For Merge/Defer decisions, verify the destination skill or reference owner is named.

Risk-based floor:

• R0-R1: evidence inspected and output self-checked.
• R2: inspect resulting diff or local state.
• R3: verify local state and report recovery limits.
• R4-R5: require explicit confirmation, preflight evidence, and post-action verification where this skill owns the action.

Output Contract

Final response must include:

## Result

- Decision, action, or artifact produced.

## Evidence

- Files, commands, diffs, refs, or assumptions used.

## Verification

- Checks performed and their result.

## Risks / Limitations

- Remaining uncertainty, blocked actions, or routed next steps.

Stop / Confirmation Rules

Stop when the repository state is dirty, conflicted, diverged, missing required evidence, or ambiguous in a way that could overwrite user work, invalidate the requested scope, or require a gated action.

Require explicit action-specific confirmation for:

• destructive local mutation.
• remote/shared mutation.
• history rewriting.
• security/secret/data impact.
• irreversible or hard-to-recover operation.

Broad approval such as "do whatever" is not enough for R4-R5 actions.

Lazy-load References

Load references/admission-rubric.md when:

• the task needs the detailed guidance described by the file name.
• the state/risk table identifies an ambiguous or high-risk path.

Load references/overlap-matrix.md when:

• the task needs the detailed guidance described by the file name.
• the state/risk table identifies an ambiguous or high-risk path.

Load references/context-budget.md when:

• the task needs the detailed guidance described by the file name.
• the state/risk table identifies an ambiguous or high-risk path.