メニュー
Define how approved requirements will be implemented (service boundaries, APIs, data model, integrations, failure modes, technical contracts) before coding.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Draft an academic paper or thesis in phases that survive peer review, from fitting the venue through shaping the contribution, storyboarding the skeleton, and writing the prose.
Pressure-test a paper at any phase, whether shape, skeleton, draft, or final, by reviewing it three ways at once, four when citations need checking against sources, then synthesize a mock notification with a phased revision list.
Build a single-file HTML slide deck in three light passes, content and mechanics first, then a unique visual identity, then the assembled deck, so revising the sequence never means regenerating the whole file.
Use after implementation is committed on a branch to open or update a PR, write the PR body, link work items, monitor checks, and handle CI feedback. Works for a feature or a standalone fix/perf/refactor.
Record an architecture decision by creating, updating, or superseding an ADR after a significant, costly-to-reverse technical choice is approved.
Explore how something should work before building it (product philosophy, component design, or feature behavior) and converge on an approved design.
| name | architecture-design |
| description | Define how approved requirements will be implemented (service boundaries, APIs, data model, integrations, failure modes, technical contracts) before coding. |
| allowed-tools | Read, Grep, Glob, Write, Edit |
| model | opus |
| effort | high |
The SRS defines the what; this defines the how. Produce a technical contract of decisions and constraints, not behavior. Describing what the system does means writing SRS content, so reference the requirement ID instead. UI flows live in docs/design/; an unclear requirement goes back to the SRS before design.
A single docs/architecture.md covers the product, merging each feature into the sections it affects rather than appending feature-named ones. Past the split threshold (engineering-defaults.md), keep it as an index and split concerns into docs/architecture/<concern>.md.
reference/deep-modules.md carries the vocabulary for making a module deep.project.md, vision.md, or an ADR gets one line pointing there.On a fresh docs/architecture.md: create docs/project.md first if absent (stack, global constraints, repo structure, environments), then build from docs/srs.md, with docs/product/vision.md Principles as hard constraints. On an existing one: read it and the ADRs, then merge the current feature into the sections it affects.
List open decisions that materially affect implementation. For each non-trivial one, present options before drafting:
| Option | Best for | Tradeoff | Risk |
|---|---|---|---|
| A | ... | ... | ... |
Extract the business rules for this work (calculations, validations, state transitions, limits), formatting the non-obvious ones:
Rule: [name] | Source: [RF-XXX.N] | Given / When / Then: [behavior] | Parameters: [values]
Update or create the document; for initial creation, read reference/template.md.
Self-critique before saving: simpler than the overbuilt version? Every boundary justified? A dependency failure traceable end to end? Business rules preserved? Missing values explicit rather than silently defaulted?
Save. Use adr for each decision costly to reverse.
Saved and approved. Suggest grill-me to pressure-test before implementation.