菜单
Before modularizing or refactoring a package, analyze the code for extraction points, write characterization tests for current behavior, then modularize under test protection. Use when a package has monolithic files that need to be broken into testable modules.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Pipeline for delegating one large mechanical change to a worker under a hard green-or-report gate — specify, dispatch mechanical-refactor-worker, independently re-verify the green claim, hand the working-tree diff to pr-review-reviewer, then commit. Route-only: it does no editing and forms no verdict. Use when delegating a big decision-free change on your own working tree.
Procedure for running multiple independent backlog items in parallel via worktree-isolated subagents with zero merge conflicts — partition file ownership before spawning, isolate each implementer in its own worktree, sequence overlapping work behind occupants, one coherent self-verified PR per agent, and serial orchestrator merge. Use when executing 2 or more independent items concurrently.
Thin router for the doc-vs-code architecture conformance audit (GATE-CONFORMANCE). Routes to the mechanical conformance scan plus the architecture-refresh agent loop (architecture-conformance-auditor / architecture-auditor + fixers), which own the audit behavior natively. Use before a release, after cross-package work, or when GATE-CONFORMANCE runs.
Router for the mandatory post-implementation sequence — SPEC sync, build/test, README, commit/PR, publish, content/ docs, docs deploy. Each step's detail lives in its owning skill/rule; this file only fixes the order and the gates. Execute automatically after implementation work; do not wait for the user to request it.
Orchestrator for the spec document gate pipeline. Reads current status from frontmatter, determines the next gate, invokes backlog-writer or backlog-gate-guard, and updates frontmatter status on PASS. Does nothing else.
Mandatory verification loop after any SPEC.md or contract document change. Compares spec against implementation code, fixes code to match spec, repeats until zero discrepancies, then runs regression tests. Spec is always the source of truth — never modify the spec within this workflow.
| name | pre-refactor-test-harness |
| description | Before modularizing or refactoring a package, analyze the code for extraction points, write characterization tests for current behavior, then modularize under test protection. Use when a package has monolithic files that need to be broken into testable modules. |
AGENTS.md > "Test-Driven Development"AGENTS.md > "Build Requirements"AGENTS.md > "No Fallback Policy"Never refactor without tests. Never modularize without first proving the current behavior is captured. The sequence is always: Analyze → Test → Extract → Verify.
Catalog each responsibility block in the target file(s) and classify it: pure logic (immediately extractable, highest test value — P1), I/O behind an interface (P2), framework-coupled (P3 — may need architectural discussion). Present the proposed module structure and get user approval before proceeding.
Write tests capturing the current behavior of each P1 target (input→output contracts, edge
cases, error paths; RED tests against the extracted signature if the code is inline-untestable).
Run them, then commit the tests separately before any extraction — this preserves the rollback
point (test(<pkg>): add characterization tests for <target> before refactor).
Extract one target at a time — pure move only, no behavior change ("while I'm here" fixes are the
classic failure). Run the package tests + build after each extraction and commit each individually
(refactor(<pkg>): extract <module> from <source>). P1 first; P2 needs its interface defined
before the move.
Full pnpm build && pnpm test && pnpm typecheck, then update SPEC.md file structure →
spec-code-conformance.