메뉴
Improve a skill using a test-fix-retest loop. Runs static checks, proposes targeted fixes, rewrites the skill, re-tests, and keeps or reverts based on score change.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | skill-improve |
| description | Improve a skill using a test-fix-retest loop. Runs static checks, proposes targeted fixes, rewrites the skill, re-tests, and keeps or reverts based on score change. |
| argument-hint | [skill-name] |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Write, Bash |
/skill-improve [skill-name]; project artifacts referenced below; user decisions and approvals before writes.skill_testing/catalog.yaml and skill_testing/quality-rubric.md; with approval writes memory_bank/t3_archive/skill_testing/improvements/skill-improve-[name]-[YYYY-MM-DD].md. Retest coverage is updated by /skill-test.Detect the target domain before improving a skill:
Never delete game examples while improving a skill. Move them to [Game] / [游戏专用] sections if they no longer fit the shared path.
Runs an improvement loop on a single skill: test → fix → retest → keep or revert.
Read the skill name from the first argument. If missing, output usage and stop:
Usage: /skill-improve [skill-name]
Example: /skill-improve tech-debt
Verify skills/[name]/SKILL.md exists. If not, stop with:
"Skill '[name]' not found."
Run /skill-test static [name] and record the baseline score:
Display to the user:
Static baseline: [N] failures, [M] warnings
Failing: Check 4 (no ask-before-write), Check 5 (no handoff)
If baseline is 0 FAILs and 0 WARNs, note it and proceed to Phase 2b.
Look up the skill's category: field in
skill_testing/catalog.yaml.
If no category: field is found, display:
"Category: not yet assigned — skipping category checks."
and skip to Phase 3.
If category is found, run /skill-test category [name] and record the category baseline:
Display to the user:
Category baseline: [N] failures, [M] warnings ([category] rubric)
If BOTH static and category baselines are 0 FAILs and 0 WARNs, stop: "This skill already passes all static and category checks. No improvements needed."
Read the full canonical skill file at skills/[name]/SKILL.md.
For each failing or warning static check, identify the exact gap:
context: fork set but fewer than 5 phases foundFor each failing or warning category check (if category was assigned in Phase 2b), identify the exact gap in the skill's text. For example:
If the target skill contains any of these markers, run a Product parity diagnosis before proposing fixes:
Product, [Product], [通用产品], general productproduct-concept.md, API, CLI, web, data pipeline, language specialistCheck whether the Product branch has the same implementation depth as the Game branch:
/code-review, /test-evidence-review, /release-checklist, /propagate-design-change, /setup-engine refresh, or /create-stories.Record the diagnosis:
Dual-domain parity:
- Game branch preserved: [PASS / FAIL]
- Product routing only: [YES / NO]
- Product context reads: [PASS / MISSING]
- Product steps/checks: [PASS / MISSING]
- Product output/next steps: [PASS / MISSING]
- Recommended fix: [add Product branch / expand Product output / update docs only]
Show the full combined diagnosis to the user before proposing any changes.
Write a targeted fix for each failure and warning. Show the proposed changes as clearly marked before/after blocks. Only change what is failing — do not rewrite sections that are passing.
For dual-domain parity fixes:
design/cdd/, design/ux/, docs/architecture/, production/qa/, production/releases/, tests/, and docs/reference/<stack>/.Ask: "May I write this improved version to skills/[name]/SKILL.md? This also regenerates the runtime adapters declared in cdd-manifest.toml for that skill (python scripts/sync_adapters.py --write --class skills)."
If the user says no, stop here.
Snapshot the current canonical skill file skills/[name]/SKILL.md (for revert if needed). Snapshot rollback is independent of Git/index state and restores the exact baseline from the start of this invocation — do not use git checkout.
Write the improved skill to skills/[name]/SKILL.md, then regenerate the runtime adapters: python scripts/sync_adapters.py --write --class skills.
Re-run /skill-test static [name] and record the new static score.
If a category was assigned, also re-run /skill-test category [name] and record the new category score.
Display the comparison:
Static: Before [N] failures, [M] warnings → After [N'] failures, [M'] warnings
Category: Before [N] failures, [M] warnings → After [N'] failures, [M'] warnings (if applicable)
Combined change: improved / no change / worse
Count the combined failure total: static FAILs + category FAILs + static WARNs + category WARNs.
If combined score improved (combined failure count is lower than baseline): Report: "Score improved. Changes kept." Show a summary of what was fixed in each dimension.
If combined score is the same or worse:
Report: "Combined score did not improve."
Show what changed and why it may not have helped.
Ask: "May I revert skills/[name]/SKILL.md from the pre-write snapshot?"
If yes: restore the snapshot to skills/[name]/SKILL.md, then regenerate the runtime adapters: python scripts/sync_adapters.py --write --class skills.
After the keep/revert decision, ask:
"May I write the improvement record to
memory_bank/t3_archive/skill_testing/improvements/skill-improve-[name]-[YYYY-MM-DD].md?"
Only write this file if the user approves. The record must include:
Do not update memory_bank/t3_archive/skill_testing/coverage-index.yaml here.
That index is maintained by /skill-test when retest evidence is approved.
/skill-test static all to find the next skill with failures./skill-improve [next-name] to continue the loop on another skill./skill-test audit to see overall coverage progress in memory_bank/t3_archive/skill_testing/coverage-index.yaml.Brownfield onboarding — audits existing project artifacts for template format compliance (not just existence), classifies gaps by impact, and produces a numbered migration plan. Run this when joining an in-progress project or upgrading from an older template version. Distinct from /project-stage-detect (which checks what exists) — this checks whether what exists will actually work with the template's skills.
Generate a project progress dashboard from workflow-catalog.yaml. Reads current stage, required steps, artifact evidence, validation gaps, writes production/project-roadmap.md after approval, and mirrors to memory_bank/t2_execution/current_roadmap.md when memory_bank exists.
Memory-bank governance audit — checks whether T0 laws/current state, T1 supporting context, T2 execution mirrors, adapter freshness, and T3 archive indexes align. Read-only by default; may record adapter_state.yaml only after explicit approval.
Constitution Driven Development project governance — establishes, derives, updates, or amends governing principles at any project stage. Reads existing artifacts to derive a constitution, audits alignment, tracks versions, and supports formal amendment workflow. Domain-agnostic, stage-aware unified onboarding entry.
Analyzes what is done and the users query and offers advice on what to do next. Use if user says what should I do next or what do I do now or I'm stuck or I don't know what to do
Generates a contextual onboarding document for a new contributor or agent joining the project. Summarizes project state, architecture, conventions, and current priorities relevant to the specified role or area.