메뉴
Use for refactors, restructuring, responsibility splits, dependency cleanup, architecture or module-boundary changes, and state or data flow changes. Prove that the intended structure changed rather than only names or surface code.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Use when a real side issue is found but will not be fixed within the current approved scope. Record only evidence-backed issues that can affect future work and have a concrete suggested next step.
Use when reporting task completion, verification results, blockers, failed checks, or unverified work. Require current-task evidence and clearly separate completed, verified, unverified, blocked, and recorded issues.
Use when the user asks to port, migrate, copy, or transplant an implementation while preserving behavior exactly or forbidding a rewrite. Keep the source authoritative and require approval for every deviation.
Use when work is large, risky, multi-step, or easy to shrink accidentally. Keep the full approved goal, checkpoints, verification plan, risks, and approval decisions visible. Not for ordinary low-risk work.
Use for all user-facing responses and artifacts. Write naturally in the user's language, localize ordinary source-language prose, prefer plain wording, clarify consequential ambiguity, make outputs stand alone, apply corrections beyond literal example details, keep diagnostic or rejected wording out of outputs, and keep UI text and code readable.
Use for Codex capability growth: review repeated manual work, shortlist automation candidates, check existing tools, and prepare skill/script/hook/Codex automation registration only after user approval.
SOC 직업 분류 기준
| name | proofline-refactor-proof |
| description | Use for refactors, restructuring, responsibility splits, dependency cleanup, architecture or module-boundary changes, and state or data flow changes. Prove that the intended structure changed rather than only names or surface code. |
Use assets/templates/refactor-proof-plan.md before substantial work and assets/templates/refactor-proof-report.md for detailed evidence.
State current -> intended responsibility owner, call path, dependency direction, and state/data flow. Mark a field N/A only when it is outside the requested change.
Complete only when every non-N/A intended structure is implemented and evidenced.
Evidence must include at least one real structure change:
Check old imports, paths, names, or direct calls that should be gone. Check every non-N/A new call path and dependency direction. Run relevant tests, build, typecheck, or lint. If a check cannot run, report not verified.
Do not call the refactor complete when only names changed, old code still owns the work, old imports remain without explanation, the new dependency direction is unused, or current verification evidence is missing.
