メニュー
Use when making architecture decisions, setting up CI/CD, managing technical debt, or choosing branching strategies - enforces ADR requirements and prevents resume-driven design
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when working on a Python task and unsure which specialist to load - routes to type-system, mypy-resolution, project-tooling, delinting, testing, async, scientific-computing, ML-workflows, debugging-and-profiling, or Textual-TUI specialists based on symptoms
Use when starting any UX/UI design task — visual design, IA, interaction, accessibility (WCAG 2.2), user research across mobile, web, desktop, game, and AI surfaces, plus first-principles audience-derived needs analysis. Routes to 11 specialist sheets.
Use when a Claude is taking **standing ownership** of a software product across many sessions — discovery, strategy, specs, and value validation — deciding *what to build, why, for whom,* and *whether it worked*, with continuity, decision provenance, and an authority boundary that escalates irreversible or outward-facing actions to the human owner. Owns the product disciplines: opportunity assessment (JTBD, problem validation, business case), vision/strategy/positioning and intent-roadmapping, PRDs with falsifiable acceptance criteria, delivery orchestration and acceptance, product-value metrics and experimentation, and the product anti-pattern catalog. Orchestrates rather than reimplements: routes sequencing/flow/WSJF to `/axiom-program-management`, plans to `/axiom-planning`, solution/architecture to `/axiom-solution-architect`, research method to `/lyra-ux-designer`. Do **not** load to build one feature, choose an architecture, or manage delivery flow for already-decided work.
This skill should be used when the user asks to "track work", "create an issue", "find something to work on", "what should I work on next", "triage bugs", "close an issue", "check what's blocked", "plan a milestone", "review sprint progress", "coordinate agents", or when working in a project that uses filigree for issue tracking. Provides workflow patterns, team coordination protocols, and operational guidance for the filigree issue tracker.
Use when designing a system that spans more than one process, machine, or failure domain and a partition, crash, or duplicate must not silently corrupt state. Use when you see split-brain, lost writes under partition, duplicate processing, stuck or half-applied sagas, retry storms, dual writes drifting apart, or "works in staging, melts under load." Architecture-level — how to design correctness under partial failure, not how to deploy it. Single-service API internals → `axiom-web-backend`; CI/CD and ops → `axiom-devops-engineering`; replay/seed determinism → `axiom-determinism-and-replay`; broker/event-sourcing mechanics → the event-driven pack.
Use when designing a system whose past behaviour must be recoverable as a fact — RL training substrates, multi-agent simulations, deterministic game engines, replay-debuggable services, multiplayer lockstep, or any pipeline where "I cannot reproduce that bug" is unacceptable. Use when teams disagree about what "snapshot", "seed", or "replay" mean across modules. Use when cross-machine or cross-process determinism is required, or a regulator will ask "what was the input at tick T?". Architecture-level — how to design a deterministic system. For verifying an existing simulation against known patterns, use `/check-determinism` from yzmir-simulation-foundations instead.
| name | design-and-build |
| description | Use when making architecture decisions, setting up CI/CD, managing technical debt, or choosing branching strategies - enforces ADR requirements and prevents resume-driven design |
This skill implements the Technical Solution (TS), Product Integration (PI), and Configuration Management (CM) process areas from the CMMI-based SDLC prescription.
Core principle: Architecture decisions require documentation (ADRs). Emergency shortcuts require retrospective documentation. "Best practice" is never justification - requirements are.
Use this skill when:
Do NOT use for:
| Situation | Primary Reference Sheet | Key Decision |
|---|---|---|
| "Should we use microservices?" | Architecture & Design | Requires ADR. Use decision framework: team size, domain complexity, ops maturity. |
| "Git workflow is chaos" | Configuration Management | Diagnose root cause first. GitFlow (L3 releases) vs GitHub Flow (continuous) vs Trunk (high maturity). Requires ADR. |
| "70% of time on bugs" | Technical Debt Management | CODE RED. Feature freeze, architectural audit, classify debt (architectural/tactical/unpayable). |
| "Setting up CI/CD" | Build & Integration | Requirements gathering first. Platform choice requires ADR. Start simple, add stages incrementally. |
| "Quick fix vs proper solution" | Level 2→3→4 Scaling | Level 3 requires retrospective ADR within 48 hours. Document as HOTFIX with paydown commitment. |
CRITICAL: This skill enforces governance based on project maturity level.
Check for project level in:
CLAUDE.md: CMMI Target Level: 3| Level | ADR Required For | Exception Protocol |
|---|---|---|
| Level 2 | Major architecture decisions (platform choice, deployment strategy) | Informal discussion OK, document decision in wiki/README |
| Level 3 | ALL architectural decisions (tech stack, branching strategy, design patterns, CI/CD platform) | Emergency HOTFIX: Retrospective ADR within 48 hours mandatory |
| Level 4 | Everything in L3 + quantitative justification with metrics | No exceptions - statistical baselines required |
When: Production emergency, immediate fix needed, no time for full ADR process
Level 3 Requirements:
Violation: Skipping retrospective ADR = governance failure. See Enforcement section below.
HOTFIX Frequency Limit: >5 HOTFIXes per month = systemic problem requiring architectural audit, not process exception.
Architectural decisions (ADR required):
Implementation details (no ADR required, track in code/PR):
Borderline decisions (when in doubt, write ADR):
Level 3 Requirements:
For detailed enforcement mechanisms, escalation paths, and compliance metrics, see level-scaling.md.
Detection: User says "I've heard X is best practice" or "Everyone uses Y"
Red Flags:
Counter:
Forcing function: Require ADR with alternatives analysis. If they can't justify with measurable requirements, ADR review will reject it.
Detection: Over-engineered solution for simple problem
Red Flags:
Counter: "What's the SIMPLEST solution that meets requirements? Start there. Add complexity when demonstrated need exists, not hypothetically."
Detection: No reviews, no standards, "works on my machine"
Red Flags:
Counter: Enforce basic CM practices. Level 2 minimum: branch protection, required PR reviews, CI runs on PRs.
Detection: Increasing % of time on bugs, velocity declining
Red Flags:
50% time on bugs = WARNING
60% time on bugs = CODE RED
Counter: See Technical Debt Management reference sheet. CODE RED triggers feature freeze.
Load these on-demand for detailed guidance:
| Reference Sheet | When to Use | Link |
|---|---|---|
| Architecture & Design | Making technology choices, selecting patterns, designing system structure | architecture-and-design.md |
| Implementation Standards | Establishing coding standards, code review process, documentation requirements | implementation-standards.md |
| Configuration Management | Git chaos, branching strategy decisions, release management | configuration-management.md |
| Build & Integration | Setting up CI/CD, build optimization, deployment pipelines | build-and-integration.md |
| Technical Debt Management | Team spending >40% time on bugs, debt accumulating, velocity declining | technical-debt-management.md |
| Level 2→3→4 Scaling | Understanding what rigor is appropriate for your project tier | level-scaling.md |
| Mistake | Why It Fails | Better Approach |
|---|---|---|
| "Emergency exempts process" | Creates pattern where "urgent" = skip governance, accumulating undocumented debt | Use HOTFIX pattern: retrospective ADR within 48 hours, mandatory |
| "I'll document it later" | Later never comes, loses audit trail | Document NOW (ADR takes 15 min) or schedule retrospective (48 hours max) |
| "This is too simple for ADR" | Simple decisions have big impact, lose rationale for future | If it's truly simple, ADR takes 10 min. If it takes longer, it wasn't simple. |
| "Everyone uses X, so we should" | Resume-driven design, not requirements-driven | Require measurable justification. "Everyone" is not a requirement. |
| "20% debt allocation" when 70% bugs | Treats crisis as normal problem, ensures slow death | >60% bugs = CODE RED. Feature freeze, not incremental paydown. |
| "Pick branching strategy" without diagnosis | Treats symptom (conflicts) not cause (architecture? communication?) | Root cause analysis FIRST. Git strategy is symptom, not disease. |
| Generic CI/CD template without context | Wastes time on wrong solution | Requirements gathering FIRST: build characteristics, deployment context, risk profile |
| When You're Doing | Also Use | For |
|---|---|---|
| Designing Python architecture | axiom-python-engineering | Python-specific patterns and idioms |
| Designing web API | axiom-web-backend | REST/GraphQL best practices |
| Making architecture decision | governance-and-risk | Formal DAR process for critical choices |
| Setting up testing | quality-assurance | Test strategy and coverage |
| Choosing platforms | platform-integration | GitHub vs Azure DevOps specifics |
Without this skill: Teams experience:
With this skill: Teams achieve:
Remember: "Best practice" is never justification. Requirements are. If you can't articulate the requirement, you can't justify the architecture.