メニュー
Applies the repo's architecture patterns — functional core/imperative shell, ports-and-adapters, and DI-based composition. Use when designing module boundaries, separating domain from infrastructure, or improving testability.
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 | architecture-patterns |
| description | Applies the repo's architecture patterns — functional core/imperative shell, ports-and-adapters, and DI-based composition. Use when designing module boundaries, separating domain from infrastructure, or improving testability. |
AGENTS.md > "Development Patterns"AGENTS.md > "Type System (Strict)"AGENTS.md > "Execution Safety"The binding rules live in code-quality.md (development patterns) and .agents/project-structure.md (dependency direction). This skill is a compact reminder of the three patterns to apply — not a textbook.
Functional core, imperative shell — business rules as pure functions; I/O only at the outer boundary; dependencies and data flow explicit; side-effect decisions visible in the orchestration layer.
Ports and adapters — the domain core depends on nothing external; required capabilities are interfaces (ports) owned by core/application; concrete technology lives in adapters only; wiring happens at a single composition root.
DI-based composition — composition over inheritance; constructor injection (not global imports); narrow, explicit class responsibilities; extension points modeled as interfaces/strategy objects.
Classify each responsibility as domain logic vs I/O, extract pure rules, define minimal ports for external collaborators, move API/DB/time/random/logger access into boundary adapters, inject via constructors, and wire only at the composition root. Test the core with table-driven unit tests (no mocks needed for pure logic) and the shell with integration tests.
Watch for: hidden I/O inside "pure" utilities, framework objects passed into domain functions, adapter-driven interfaces that leak vendor details, fat orchestrate-everything services, and static/global state as implicit DI.