القائمة
Formalize an approved design into a versioned requirements specification (what the system must do, for whom, under which constraints) before architecture.
التثبيت باستخدام 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.
Define how approved requirements will be implemented (service boundaries, APIs, data model, integrations, failure modes, technical contracts) before coding.
| name | srs |
| description | Formalize an approved design into a versioned requirements specification (what the system must do, for whom, under which constraints) before architecture. |
| allowed-tools | Read, Grep, Glob, Write, Edit |
| model | opus |
| effort | medium |
The SRS defines the what; architecture defines the how. Translate the approved brainstorming design into versioned, verifiable requirements.
A single docs/srs.md covers the product, organized by domain, appending new RF-XXX domain sections per feature. Past the split threshold (engineering-defaults.md), keep docs/srs.md as an index and split domains into docs/requirements/<domain>.md.
State observable system behavior only. Each requirement earns its place here by not belonging elsewhere:
docs/design/.docs/architecture.md.docs/adr/.RF-XXX.N (a 2 to 4 letter domain code plus sequence), non-functional RNF-XXX.N. IDs are permanent; a deprecated requirement keeps its number and gains ~~strikethrough~~ with a note.Draft → Accepted → Deprecated.[RF-ANC.1](#rf-anc1).docs/product/vision.md if present; its Principles and Anti-goals are hard filters. A requirement that contradicts one is a blocking issue, so resolve it with the user before writing, rather than softening the principle to fit.docs/srs.md, read docs/product/discovery.md if present, else proceed from the approved design and name the missing inputs and the assumptions filling them. On an existing one, read it, then append the new feature's RF-XXX sections and leave existing requirements as they are.reference/template.md. Save docs/srs.md.Saved and approved. Suggest architecture-design for the how, and the ux-design agent in parallel when the UI is significant.