agentleFS
mayankjain1815-commitsmayankjain1815-commits/CITADEL/skills/improve/SKILL.md

improve

Skill4 starsChanged 4 months agoMITView on GitHub

Autonomous quality improvement loop. Scores a target against a rubric, selects the highest-leverage axis, attacks it, verifies, documents, and loops. No pre-planning between iterations — each loop re-scores from scratch.

66 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use deploy-platform, setup-platform and 7 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • agno-agiSkill

    deploy-platform

    Deploy this AgentOS using its own provider instructions, configure JWT verification, and verify the public service. Use for first deployment, redeployment, or production configuration changes.

    Also in 4 projects that use this

  • agno-agiSkill

    setup-platform

    Set up this AgentOS from a fresh clone — confirm Docker, configure .env, boot the containers, prove the MCP endpoint live, connect the AgentOS UI, then build the user's first agent. Use when the user asks to set up the platform, get started, or bring this repo up on a new machine.

    Also in 4 projects that use this

  • MicrosoftSkill

    create-agent

    Create a new MCS2 Copilot Studio agent and PAC-connected local workspace with `pac copilot init`, then optionally add modern instructions, skills, tools, knowledge, and settings before synchronizing it. Use when the user asks to create, scaffold, initialize, or build a Copilot Studio agent.

    Also in 5 projects that use this

  • AmirofcodesSkill

    goal

    Use when the user starts, manages, or asks about an OpenClaw goal mode with /goal. Enforces a bounded goal contract, visible progress blocks, proof requirements, stop conditions, and honest limitation language when no runtime goal-loop plugin is active.

    Also in 4 projects that use this

  • JetBrainsSkill

    doc-sync

    Keeps IdeaVim documentation in sync with code changes. Use this skill when you need to verify documentation accuracy after code changes, or when checking if documentation (in doc/, README.md, CONTRIBUTING.md) matches the current codebase. The skill can work bidirectionally - from docs to code verification, or from code changes to documentation updates.

    Also in 3 projects that use this

  • SentrySkill

    spec

    Produce a verified spec — problem, desired outcome, and acceptance criteria — before building. Use when given a GitHub/Linear issue link, when starting from a fuzzy in-conversation idea, or asked to "figure out what to do" / "scope this" / "what should I build" — whenever the *what* isn't yet pinned down. Grills the ambiguities, checks the premise against the code, and produces acceptance criteria you sign off on — then hands to design-first.

    Also in 5 projects that use this

  • +3 more from agno-agi

The file

Show its rules and text

We split this skill into the rules it gives an agent

35 rules. 0 are common, 17 are distinctive, and 18 are very specific to this project.

  • 0

    Common

    Most of the 63 edited versions we read keep these.

  • 17

    Distinctive

    This author's own choices. Worth a look.

  • 18

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If no rubric exists, run Phase 0 first.

    line 41
  2. Very specific:

    When invoked with --n or --continue, improve operates in campaign mode and maintains a campaign file that daemon can attach to.

    line 45
  3. Very specific:

    Update phase_within_loop at each phase: scoring → selected-{axis} → attacking-{axis} → verifying → not-started.

    line 53
  4. Very specific:

    Read .planning/campaigns/improve-{target}.md — error if missing or status not active

    line 59
  5. Very specific:

    If completed_loops >= total_loops: mark completed, exit

    line 60
  6. Very specific:

    If phase_within_loop is not not-started: restart current loop from Phase 1 (interrupted mid-loop)

    line 61
  7. Very specific:

    Run only when .planning/rubrics/{target}.md does not exist.

    line 68
  8. Very specific:

    Read competitive research from .planning/research/ if available

    line 70
  9. Distinctive:

    If the AskUserQuestion tool is available, present the gate with it.

    line 76
  10. Distinctive:

    If unavailable: ask as a plain text question and wait.

    line 77
  11. Very specific:

    Write approved rubric to .planning/rubrics/{target}.md

    line 79
  12. Very specific:

    If any two evaluators disagree by > 3 points: flag the axis as needs-refinement

    line 99
  13. Very specific:

    If --axis flag was set, skip selection and attack the specified axis.

    line 121
  14. Very specific:

    ISOLATION MANDATE: When dispatching to /experiment, /fleet, or /research --parallel, always use the Agent tool with isolation: "worktree".

    line 133
  15. Very specific:

    Artifact archiving: when the attack tried multiple approaches, write a decision record to the loop log: APPROACH COMPARISON: [approach A] …

    line 144
  16. Distinctive:

    After the attack, re-score only the targeted axis (not full re-score).

    line 148
  17. Distinctive:

    Run the four verification tiers from the rubric for the targeted axis:

    line 150
  18. Distinctive:

    Structural: verify the structural requirements are met

    line 152
  19. Distinctive:

    A behavioral FAIL overrides a passing perceptual score: Do not commit on behavioral FAIL.

    line 158
  20. Distinctive:

    If any previously passing axis now fails programmatic: abort, do not commit

    line 163
  21. Distinctive:

    If perceptual estimate suggests any axis dropped > 0.5 from baseline: abort, do not commit

    line 164
  22. Distinctive:

    Write the loop log. Always.

    line 172
  23. Very specific:

    All proposals go to .planning/rubrics/{target}-proposals.md.

    line 184
  24. Distinctive:

    All axes >= 8.0: exit with "target has reached quality ceiling"

    line 191
  25. Distinctive:

    No axis improved > 0.5 in either of the last 2 loops AND no programmatic cap is active AND at least 3 loops have completed: trigger …

    line 192
  26. Distinctive:

    On Level-Up: do not exit. Escalate. See Level-Up Protocol section.

    line 196
  27. Very specific:

    Write .planning/rubrics/{target}-level-{n}-final.md with: date, loops completed, final scorecard, axes at ceiling (≥9.0 — their 10 anchors …

    line 217
  28. Very specific:

    Write to .planning/rubrics/{target}-proposals.md: re-anchored axes (current 10 anchor, proposed 0/5/10), proposed new axes, axes proposed …

    line 225
  29. Distinctive:

    Do not self-approve. Do not continue looping.

    line 229
  30. Distinctive:

    No rubric: run Phase 0, halt for human approval.

    line 245
  31. Distinctive:

    Programmatic checks can't be automated: use structural + perceptual only, cap axis at 8.

    line 247
  32. Distinctive:

    No improvement this loop: document as "no-change", apply recency penalty.

    line 248
  33. Very specific:

    --continue + completed: do not resume, report final scorecard.

    line 253
  34. Very specific:

    --n + existing active campaign: treat as --continue. If completed/parked: new campaign, incremented slug.

    line 254
  35. Very specific:

    Proportionality: No rubric + no explicit request → suggest /review.

    line 276

“Common” is measured: kept by at least 6 in 10 of the 63 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/improve — Autonomous Quality Engine

Orientation

Use when: Scoring a target against a rubric and iteratively improving it. Rubric required at .planning/rubrics/{target}.md (Phase 0 creates one if missing).

Don't use when: Refactoring without a rubric (use /refactor), one-time code review (use /review), or debugging a specific bug (use /systematic-debugging).

Invocation

/improve {target}            # Loop until plateau or all axes >= 8.0
/improve {target} --n=3      # Run exactly N loops then stop
/improve {target} --axis={name}  # Force-attack a specific axis (skips scoring)
/improve {target} --score-only   # Score and report, no attack
/improve {target} --continue     # Resume from campaign state (used by daemon)
/improve citadel             # Targets Citadel itself

target is a slug that maps to .planning/rubrics/{target}.md. If no rubric exists, run Phase 0 first.

Campaign Mode

When invoked with --n or --continue, improve operates in campaign mode and maintains a campaign file that daemon can attach to.

Campaign file: .planning/campaigns/improve-{target}.md, created automatically on the first invocation with --n (full template: docs/QUALITY_LOOPS.md#campaign-file-template). Frontmatter: version, id (improve-{target}-{ISO-date-slug}), status: active, type: improve, target, total_loops ({n} or unlimited), completed_loops: 0, current_level (from rubric frontmatter), estimated_cost_per_loop: 12, started. Body: status and direction lines, a Loop History table (Loop | Axis Attacked | Outcome | Score Movement), and a Continuation State block (next_loop, last_scorecard_log, last_outcome, phase_within_loop, level_up_triggered).

Campaign lifecycle

Update phase_within_loop at each phase: scoring → selected-{axis} → attacking-{axis} → verifying → not-started.

On loop complete: increment completed_loops, update next_loop/last_scorecard_log/last_outcome, append Loop History row.

The --continue flag

  1. Read .planning/campaigns/improve-{target}.md — error if missing or status not active
  2. If completed_loops >= total_loops: mark completed, exit
  3. If phase_within_loop is not not-started: restart current loop from Phase 1 (interrupted mid-loop)
  4. Load last_scorecard_log for delta comparison, then run Phase 1 onwards

Protocol

Phase 0: Rubric Bootstrap (one-time, requires human approval)

Run only when .planning/rubrics/{target}.md does not exist.

  1. Read competitive research from .planning/research/ if available
  2. Spawn /research --parallel to survey comparable products if no research exists
  3. Draft 8-14 axes organized into 3-5 categories, each with:
    • Weight (0.0–1.0), Category, three anchors (0/5/10), verification specs (programmatic/structural/perceptual), research inputs
  4. Present draft rubric to the user with rationale for each axis
  5. STOP. Do not proceed until the user approves the rubric.
    • If the AskUserQuestion tool is available, present the gate with it. Options: "Approve as drafted", "Adjust axes", "Adjust weights". On adjust: revise, re-present.
    • If unavailable: ask as a plain text question and wait.
    • Record the answer in the campaign file as rubric_approved: {answer}.
  6. Write approved rubric to .planning/rubrics/{target}.md

Phase 1: Score

Score every axis in the rubric. No shortcuts. No cached scores from the previous loop.

1a. Programmatic checks (run first, in parallel)

Execute the programmatic verification steps from the rubric. A programmatic failure caps that axis at 5 regardless of evaluator scores. Record raw results: which checks passed, which failed, what the failure was.

1b. Structural analysis

Execute the structural checks from each axis's verification spec: file path existence, frontmatter schema consistency, benchmark coverage ratios, link rot, and cross-reference accuracy (check descriptions: docs/QUALITY_LOOPS.md#structural-check-types).

1c. Perceptual scoring panel (three independent evaluators)

Spawn three evaluator agents in parallel. Each receives the rubric with all axis definitions and anchors, read access to the target, its persona (A/B/C as defined in the rubric's Scoring Protocol), and the instruction to score every axis 0-10 with a one-sentence justification per axis (input list: docs/QUALITY_LOOPS.md#evaluator-panel).

Each evaluator scores independently. For each axis:

  • Final score = minimum of the three evaluators (plus programmatic cap if applicable)
  • If any two evaluators disagree by > 3 points: flag the axis as needs-refinement

needs-refinement axes are logged but still scored. Do not halt on evaluator disagreement.

1d. Compile scorecard

Compile a table with columns Axis | A | B | C | Prog | Final | Delta | Flag (layout: docs/QUALITY_LOOPS.md#scorecard-format). Final = min(A, B, C), then apply programmatic cap (sets Flag=cap). Delta = current − prior loop score (empty on loop 1).

Phase 2: Select

Choose the single axis to attack this loop.

Selection formula:

score(axis) = (10 - current_score) × weight × effort_multiplier × recency_penalty
  • effort_multiplier: low = 1.0, medium = 0.7, high = 0.4
  • recency_penalty: 0.5 if attacked in previous 2 loops, otherwise 1.0
  • Effort tiers: low < 1hr, medium 1-3hrs, high 3+hrs

If --axis flag was set, skip selection and attack the specified axis.

Announce the selection:

Selected: {axis_name} (score: {n}/10, weight: {w}, effort: {e}, selection score: {s})
Rationale: {one sentence on why this axis now, not another}

Phase 3: Attack

Execute the improvement. Dispatch strategy depends on the axis category (expanded per-category playbooks: docs/QUALITY_LOOPS.md#attack-dispatch-strategies).

ISOLATION MANDATE: When dispatching to /experiment, /fleet, or /research --parallel, always use the Agent tool with isolation: "worktree". Sub-agents in worktrees get their own context windows; the orchestrator only receives their HANDOFF results.

CategoryDispatchVerification
technical/experiment with before/after comparison; speculative worktrees (Agent + isolation: "worktree") for approaches that might conflictnode scripts/run-with-timeout.js 300 node scripts/test-all.js as the oracle
documentationdirect: read current docs, fix specific gaps; cross-reference every claim against sourcestructural verification before committing
experiencestructural fixes + doc updates; run the actual install flow in a clean temp dir; inject synthetic failures per the programmatic spec/qa
positioning/research to verify the competitive landscape is accurate, then update README/FAQ/demo copy/qa confirms the updated page renders
presentationtargeted changes per rubric anchors (no rewrites unless score is below 3)/live-preview or /qa confirms visual changes render
securityread the specific hooks/scripts involved, make targeted code changesrun the rubric's programmatic verification steps directly

Artifact archiving: when the attack tried multiple approaches, write a decision record to the loop log: APPROACH COMPARISON: [approach A] vs [approach B] — winner: [A] because [reason].

Phase 4: Verify

After the attack, re-score only the targeted axis (not full re-score).

Run the four verification tiers from the rubric for the targeted axis:

  1. Programmatic: execute the specific checks, confirm they now pass
  2. Structural: verify the structural requirements are met
  3. Perceptual: spawn a single evaluator agent (Evaluator B — Newcomer) and score just the targeted axis
  4. Behavioral simulation: clone the repo into a temp directory and follow INSTALL.md exactly as written — no prior knowledge, no shortcuts. Measure whether each step completes without error and record wall time to first successful /do command.
    • Required when targeted axis is: onboarding_friction, error_recovery, documentation_accuracy, command_discoverability
    • Optional for all other axes
    • Result: PASS {wall_time} or FAIL at step {n}: {what broke}
    • A behavioral FAIL overrides a passing perceptual score. Do not commit on behavioral FAIL.
    • Skip only if the targeted axis could not plausibly affect the user path. Plausible = axis governs code shown/executed in the app, or controls presence/absence of a UI element. Safe to skip: documentation axes (comments, docstrings), configuration-only axes, developer-tooling-only axes (e.g., visual_coherence, api_surface_consistency)

Regression check (run on all axes, not just targeted):

  • Re-run programmatic checks on every axis that shares files with the changes
  • If any previously passing axis now fails programmatic: abort, do not commit
  • If perceptual estimate suggests any axis dropped > 0.5 from baseline: abort, do not commit

On abort: revert the changes, log the failure, treat as "no improvement this loop".

On pass: commit the changes with a descriptive message.

Phase 5: Document

Write the loop log. Always. Even on abort.

Log path: .planning/improvement-logs/{target}/loop-{n}.md

Required sections (full template: docs/QUALITY_LOOPS.md#loop-log-template):

  • Header: date, loop number, selected axis, outcome (improved | no-change | aborted)
  • Scorecard: per-axis prior score, current score, delta
  • Attack summary: what was changed, approach (experiment / direct / research+update), files touched, plus the APPROACH COMPARISON record if multiple approaches were tried
  • Verification results: programmatic PASS/FAIL, structural PASS/FAIL, perceptual {score}/10 with one-line rationale, behavioral PASS {wall_time} | FAIL at step {n}: {reason} | SKIPPED
  • Proposed axis additions: PROPOSED AXIS: {name} | Rationale | Category | Weight | Anchors: 0=... 5=... 10=... (or: None proposed this loop.)
  • What was learned: 2-3 sentences

All proposals go to .planning/rubrics/{target}-proposals.md. Never to the live rubric.

Phase 6: Loop or Exit

Exit conditions (check in order):

  1. --n flag was set and N loops have completed: exit, report scorecard
  2. All axes >= 8.0: exit with "target has reached quality ceiling"
  3. No axis improved > 0.5 in either of the last 2 loops AND no programmatic cap is active AND at least 3 loops have completed: trigger Level-Up Protocol 3a. A programmatic cap IS active AND the capped axis has not improved for 2 loops: trigger Level-Up Protocol. The cap is preventing score movement, not enforcing a ceiling — do not loop indefinitely.
  4. The user said stop: exit immediately

On Level-Up: do not exit. Escalate. See Level-Up Protocol section.

On ceiling (all >= 8.0): report the final scorecard and recommend a Level-Up run.

On normal loop: return to Phase 1. Re-score everything from scratch.

Campaign mode exit handling:

  • n-complete (all loops done): set status: completed, move to completed/
  • ceiling (all axes >= 8.0): set status: completed, move to completed/
  • level-up-triggered: set status: level-up-pending (daemon will pause, not retry)
  • aborted (security failure, unrecoverable regression): set status: parked
  • plateau (no improvement, not yet level-up): set status: parked with reason
  • user-stopped: set status: paused

Level-Up Protocol

Triggers when no axis improved > 0.5 in the last 2 consecutive loops, no programmatic cap is active, and at least 3 loops have completed.

Step 1: Freeze the snapshot

Write .planning/rubrics/{target}-level-{n}-final.md with: date, loops completed, final scorecard, axes at ceiling (≥9.0 — their 10 anchors become Level {n+1}'s 5 anchors), and axes that plateaued below 9.0 with why.

Step 2: Write proposals

For each axis: propose Level {n+1} re-anchoring (current 10 → new 5, propose new 10). For plateaued axes: re-anchor, replace with measurable proxy, or retire.

Auto-include these three process axes if not already in the rubric: decomposition_quality, scope_appropriateness, verification_depth.

Write to .planning/rubrics/{target}-proposals.md: re-anchored axes (current 10 anchor, proposed 0/5/10), proposed new axes, axes proposed for retirement.

Step 3: Halt -- human approval required

Do not self-approve. Do not continue looping.

In campaign mode: set status: level-up-pending, set level_up_triggered: true, and write awaiting: human approval of level-up proposals to Continuation State.

Report: what was achieved at this level (scorecard summary), the proposals file location, and what the expected new gains look like at the next level.

The loop resumes only when the human edits the live rubric with approved proposals and sets the campaign status back to active. Level {n+1} loops continue incrementing the loop number (they do not reset to 1).

Step 4: Historical context for future evaluators

When the loop resumes after a level-up, every evaluator in Phase 1c receives the level-{n}-final.md snapshot as a reference baseline, plus the instruction: "Scores from the previous level are the floor. A score of 5 at Level 2 means you have reached what was the ceiling at Level 1."

Fringe Cases

  • No rubric: run Phase 0, halt for human approval. Never improvise.
  • Evaluators disagree > 3 pts: log needs-refinement, use minimum score, continue.
  • Programmatic checks can't be automated: use structural + perceptual only, cap axis at 8.
  • No improvement this loop: document as "no-change", apply recency penalty.
  • Loop 1 (no prior logs): delta fields empty — expected.
  • Security axis fails programmatic: halt and report. Blocking.
  • --continue + no campaign file: error, suggest --n.
  • --continue + level-up-pending: halt, point to proposals file, require human approval then status: active.
  • --continue + completed: do not resume, report final scorecard.
  • --n + existing active campaign: treat as --continue. If completed/parked: new campaign, incremented slug.

Quality Gates

  • Phase 0 requires human approval. No exceptions.
  • Phase 4 regression check must run. No committing without it.
  • Phase 4 behavioral simulation result must appear in the loop log for applicable axes. Behavioral FAIL blocks commit regardless of perceptual score.
  • Phase 5 loop log must be written. Even on abort, even on no-change.
  • Perceptual scoring: all three evaluators required for Phase 1. Single evaluator acceptable for Phase 4 spot-check only.
  • Selection formula must be shown in output.
  • Any axis with a programmatic failure is capped at 5. Cannot be overridden.
  • The loop never writes to the live rubric. Proposals go to .planning/rubrics/{target}-proposals.md only. Human approval required.
  • Level-Up Protocol requires human approval before resuming
  • Campaign mode: campaign file must be updated after every phase transition and every loop completion.
  • Campaign mode: level-up must set status: level-up-pending, not parked or active.

Contextual Gates

Disclosure: State loop count, target, per-loop cost (~$12), total estimate. For --continue: loops remaining and spend so far. For unlimited: state exit conditions (plateau or all axes >= 8.0).

Reversibility: Green = --score-only | Amber = standard loops (each commits separately) | Red = level-up (rewrites rubric anchors permanently). Red requires explicit confirmation.

Proportionality: No rubric + no explicit request → suggest /review. All axes > 8.0 + --n=1 → suggest --axis. Cost > $50 → confirm.

Trust gating: Novice (0-4): --score-only / --n=1 only. Familiar (5-19): up to --n=5. Trusted (20+): no cap; confirm unlimited or cost > $50.

Exit Protocol

---HANDOFF---
- Target: {target} — Loop {n} of {n_total or "∞"} — Level {current_level}
- Outcome: {improved | plateau | ceiling | aborted | n-complete | level-up-triggered}
- Score movement: {axis} {before} → {after} (+{delta})
- Behavioral simulation: {PASS {wall_time} | FAIL | SKIPPED}
- Proposed rubric additions: {count} — written to .planning/rubrics/{target}-proposals.md
- Loop log: .planning/improvement-logs/{target}/loop-{n}.md
- Reversibility: amber -- each loop commits separately, revert individual loops with git revert
- Next recommended axis: {axis_name} (if not exiting)
- Level-up snapshot: .planning/rubrics/{target}-level-{n}-final.md (if level-up triggered)
---

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.