[Documentation] Use when generating, smart-merging or refactoring the root AI context (CLAUDE.md, AGENTS.md) and its Claude/Codex projections. Config file only: project-config.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
[Workflow] Restructure existing code while preserving observable behavior, proven by baseline and final tests plus change review.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
설치 방법 보기설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
Read the registry → workflows.workflow-refactor together with this skill. Call /start-workflow workflow-refactor to resolve the selected mode, pre-actions and fingerprint.
Todo FIRST: before triage, analysis or step execution, create one todo per phase of the selected mode, in order, listing every occurrence of that phase as a line, including conditional/optional ones (a mode that declares no phases gets one todo per occurrence); preserve occurrence IDs, roles and barrier groups. Use native todo tools or an equivalent persistent ledger. Then mark the first todo in_progress; close each step line with its run or skip evidence, and complete a phase todo only when every line is closed and its applicable exit gates hold.
Mode selection and registry loading prepare tracking; any 'first action' below means the first substantive action after this bootstrap.
Call each step skill: read its linked SKILL.md and execute its protocol through the active host with the registry args. Reading or naming a skill alone is not execution. Required gates and core/optional flex follow the linked start-workflow Step Execution Protocol; keep this skill's quality gates, loops and evidence requirements.
Conditions: load each occurrence's registry applicability.when and skipReason verbatim, and record its run/skip evidence through the linked start-workflow protocol. Do not silently omit a todo or turn a conditional skill into an unconditional call; close, in one batch at triage, the todos whose condition is already false there. Declared parallel groups retain their all-return barrier.
Explicit step-skill calls by mode (registry order; roles and conditions remain owned by the registry):
default: /investigate (core) → /integration-test (optional; conditional) → /test (gate) → /plan (core) → /plan --mode=validate (optional; conditional) → /plan --mode=execute (core) → /spec [mode=tests] (optional; conditional) → /work-item --mode=review --type=spec-tests (optional; conditional) → /spec [mode=sync] (optional; conditional) → /workflow-review-changes --tests=defer (gate) → /integration-test --mode=verify (optional; conditional) → /test --proven=@verify (gate) → /workflow-end (gate) → /watzup (optional; conditional)
Phase todos: Discover (3) → Plan (2) → Build (4) → Review (1; exit review-converged) → Verify (2; exit tests-pass) → Close (2; exit run-closed)Regenerate this block with node .claude/scripts/lib/workflow-skill-contract.cjs --write after registry edits; /sync-codex refreshes it before mirroring.
Goal: Restructure existing code without changing its observable behavior, proven by the same test scope green before and after the change plus a converged change review — cheap on a small local cleanup, thorough on a wide or risky restructure.
Use this to restructure, reorganize, rename, extract, simplify or pay down technical debt while behavior stays fixed. A change the user wants to behave differently is a feature (workflow-feature) or a bugfix (workflow-bugfix); a single trivial rename in one file fits a direct edit plus test and review.
Key rules:
docs/project-config.json → workflowPatterns.Classify the refactor before choosing steps and record the result in the workflow report:
| Triage result | Typical route through the recommended skills |
|---|---|
| XS/S, one module, no contract/data surface | investigate → baseline test → short plan (the plan's light profile) → execute → review → test → close |
| M, or cross-module | keep one lean plan; add characterization tests, before the baseline run, where the investigation shows a coverage gap |
| L/XL, public contract/data/security, or ambiguous target structure | add /plan --mode=validate; execute in bounded batches per module with one report per batch, baseline and final test per batch plus a full-scope final run |
Non-negotiable — /workflow-end checks each against its evidence before the run closes:
/test, gate, before any change) — the test command, scope and pass summary for the code the refactor touches, including any characterization tests written just before it. A red existing test stops the refactor: report it, or route the failure to workflow-bugfix; never refactor on a red base. A red characterization test written in this run gets a five-way verdict first: a test-authoring fault is corrected and re-run once on the unrefactored tree; a real defect stops the refactor like an existing test./test --proven=@verify, gate, after the change and after review fixes) — the baseline scope plus any characterization tests run green in THIS run, through /integration-test --mode=verify when it runs (it owns the mutation check) and /test for every tier that verify report does not cover; when the verify step does not run, the main session owns any mutation check. Test code changed only mechanically (imports, renamed symbols, moved paths)./workflow-review-changes, gate, INLINE in the main session) — validated blocking findings fixed and the fixed state re-reviewed./workflow-end (top-level only).Specs normally do not change in a refactor; the spec steps below run only when a preserved invariant lacks a TC (/spec [mode=tests]) or canonical specs or TCs point at code or tests the refactor moved (/spec [mode=sync]). Any observable behavior, public contract or docs/spec boundary change means the work is no longer a pure refactor — stop and confirm with the user, then run the spec/test/docs sync that change requires.
Step contract: /start-workflow owns how gate, core and optional steps run; this table summarizes this workflow's intent, outcomeGates and step roles from .claude/workflows.json, in its recommended default order.
| Step | Role | Runs when / earns its cost | Proves |
|---|---|---|---|
/investigate | core | always in practice — scope, callers, 3+ local pattern examples | scope and target pattern |
/integration-test | optional | touched behavior has no test that would fail if it changed — written before the baseline run | characterization tests |
/test | gate | always — BEFORE any change, on the affected scope plus any characterization tests (one pre-change run) | baseline green |
/plan | core | always in practice; XS/S keeps it to files, steps, rollback (light profile) | refactor plan |
/plan --mode=validate | optional | size L+, or an ambiguous target structure or scope | plan confirmed |
/plan --mode=execute | core | always in practice — small verifiable increments | the change |
/spec [mode=tests] | optional | a preserved invariant lacks a TC; moved or renamed paths go to the spec sync | TCs match |
/work-item --mode=review --type=spec-tests | optional | TC content changed beyond evidence paths | TC quality |
/spec [mode=sync] | optional | specs/TCs reference moved or renamed code/test paths | specs match |
/workflow-review-changes --tests=defer | gate | always — INLINE in the main session | review converged |
/integration-test --mode=verify | optional | integration tests written or changed in this run, or core logic moved — after the review; owns the mutation check | integration tests green, mutants killed |
/test --proven=@verify | gate | always — after the change and review fixes, baseline scope; runs only the tiers this run's verify report does not cover | behavior preserved |
/workflow-end | gate | always | run closed — prints the recap when /watzup does not run |
/watzup | optional | a session report was requested, or several workflows need one handoff | consolidated session report |
Outcome gates: tests pass · review converged · run closed.
A recommended step the triage shows would do no real work is not run; record it through the Step Execution Protocol with its evidence.
Ad hoc skills (not registry steps): /investigate again before removing "unused" code — grep evidence, confidence ≥80%, cross-module/service check · /performance-review for a performance-driven refactor (below) · /code-simplifier for a clean-up pass, only before the review and final test so they cover its result.
[PERFORMANCE-SDD ROUTE] A performance-driven refactor (query optimization, caching, fewer allocations, throughput) runs
/performance-reviewfor benchmark evidence — SLA, baseline, measurement command — while preserving observable behavior and functional no-regression checks. A pure behavior-preserving optimization adds no new TCs when the invariant-preservation evidence and the final/testgate cover it; a changed SLA, performance constraint, state timing boundary, public contract or docs/spec boundary still requires spec, test and docs sync.
You choose inline vs sub-agent, parallel waves vs sequential, batching and order — optimize wall-clock and token cost at equal quality. Fixed constraints (data dependencies):
/plan --mode=execute changes it.--tests=defer) and the verify and final test run after it; a fix made by the verify step re-runs /workflow-review-changes --tests=defer (SYNC:verify-last-order); when /integration-test --mode=verify does not run, the main session owns any mutation check; /workflow-end runs last./workflow-review-changes runs INLINE in the main session — never as a sub-agent — and owns the test-quality review and the docs/domain-entity reference refresh; do not repeat them here.Recommended: XS/S work inline without sub-agents; L/XL mechanical changes applied per module batch with a bounded report each, then one full-scope final test.
tmp/reports/workflow-refactor-{YYMMDD}-{HHmm}-{slug}.md before the first finding; append triage, baseline evidence, pattern examples, batch results and deviations per step; re-read it and TaskList after compaction. Sub-agent briefs make report-writing their first deliverable.ask user question tool.Activate the workflow-refactor workflow: run /start-workflow workflow-refactor with the user's prompt as context. Apply the shared SDD Artifact Contract from shared/sdd-artifact-contract.md in the active skills root; project conventions come from docs/project-config.json and the docs index.
Recommended default order (roles in the table above):
IMPORTANT MANDATORY Steps: /investigate -> /integration-test -> /test -> /plan -> /plan --mode=validate -> /plan --mode=execute -> /spec [mode=tests] -> /work-item --mode=review --type=spec-tests -> /spec [mode=sync] -> /workflow-review-changes --tests=defer -> /integration-test --mode=verify -> /test --proven=@verify -> /workflow-end -> /watzup
<!-- PROTOCOL-GUIDES:START -->Protocol guides — Apply each protocol only when its read-when condition holds. If a protocol's text is not in your context, read its file below before you act on it.
incremental-persistence — Persist results per file or section while the work proceeds; a sub-agent or heavy step processes more than three files → .claude/skills/shared/protocols/incremental-persistence.mdsession-goal-ledger — Keep the original goal and every user prompt of the session; running a long or multi-prompt session → .claude/skills/shared/protocols/session-goal-ledger.mdsubagent-return-contract — Sub-agents return a structured envelope and a report path, never an inline report; spawning a sub-agent → .claude/skills/shared/protocols/subagent-return-contract.mdverify-last-order — Build all phases and write tests, review statically, then verify once with a mutation check; planning or running any code-changing task → .claude/skills/shared/protocols/verify-last-order.mdworkflow-registry-binding — Read the workflow registry entry and the workflow skill together, since they must agree; executing or editing a workflow → .claude/skills/shared/protocols/workflow-registry-binding.mdTask Planning Rules: pin Original goal:, keep User prompts this session: P1…Pn, and map the result to every prompt before claiming done; full text: .claude/skills/shared/protocols/session-goal-ledger.md.IMPORTANT MUST ATTENTION Goal: restructure existing code without changing its observable behavior, proven by the same test scope green before and after plus a converged change review.
/test (gate) proves them and the existing scope green BEFORE any change; the final /test (gate) green on the same scope AFTER the change.workflowPatterns; removing "unused" code needs /investigate evidence./workflow-review-changes runs INLINE in the main session; close with /workflow-end.아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
[Documentation] Use when generating, smart-merging or refactoring the root AI context (CLAUDE.md, AGENTS.md) and its Claude/Codex projections. Config file only: project-config.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
[Code Quality] Use when a workflow step or the user asks for AI code or plan review: LLM calls, prompts, agents, RAG, evals and guardrails. --mode={code|plan}; --report-only is read-only.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
[Architecture] Use when a workflow step or the user asks for architecture design, compliance review, scalability grading or whole-project audit via --mode={design|review|scalability|full}.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
[Content] Use when a workflow step or the user asks for product/feature ideation with ranked opportunities and validation tests. --mode={roadmap|scope}.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
[Content] Use when a workflow step or the user asks for business viability: Business Model Canvas, financials, risks and go-to-market recommendation.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
[Code Quality] Use when a workflow step or the user asks for a focused code-change review: staged, unstaged, branch diff or simple pull request. --fix-loop fixes and re-reviews. Complex pull request: workflow-review-changes; rationale: why-review.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.