القائمة
Use when evaluating a proposed change to a system described in a blueprint — a new feature, behaviour change, rule modification, or scope expansion. Convenes the review panel.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
A living product specification skill. Use when you want to document how a system works, capture user stories and flows, build shared vocabulary, discuss existing functionality, or create a single source of truth for a feature or product area.
Use when reviewing an existing blueprint for gaps, missing flows, terminology conflicts, coverage of error cases, or untestable requirements.
Use when a system already exists but is not documented — to capture how it actually works, build shared vocabulary around it, and produce a living spec that the team can reason about and discuss.
Use when building a blueprint from scratch through conversation — specifying a new feature, capturing a planned system, or turning stakeholder descriptions into a structured living spec.
Use when reviewing a draft or existing blueprint for quality — missing scenarios, terminology gaps, unclear requirements. Convenes the review panel for a structured debate.
Use when creating a new blueprint — generates the full directory structure with placeholder files and inline hints for each section.
| name | propose |
| description | Use when evaluating a proposed change to a system described in a blueprint — a new feature, behaviour change, rule modification, or scope expansion. Convenes the review panel. |
Convene the review panel to evaluate a proposed change to a system described in a blueprint — new feature, behaviour change, rule modification, or scope expansion. For quality problems in an existing blueprint, use review instead.
Read the full blueprint before evaluating the proposal. Evaluate against coherence (does the change fit without contradicting what is specified?) and value (does it solve a real problem proportionate to the complexity it introduces?).
Simulate the review panel from . Follow debate protocol. Every panellist weighs in.
Default disposition: leave the system as described. Burden of proof is on the proposal. Every change has a cost — implementation, testing, documentation, user communication, support burden.
What limitation or need does this address? Is it real and recurring, or hypothetical? Concrete evidence — user feedback, support tickets, observed behaviour? How does it interact with existing actors, flows and domain model? Composes cleanly, or requires special cases? Changes meaning of anything currently specified? What is the minimum version that solves the problem? Is proposed scope proportionate? Over-scoped changes should be scoped down, not rejected. Implementation effort, documentation burden, user communication, support complexity? User flows that become more complicated? Existing users or integrations affected? If wrong, how hard to undo? Changes easy to add and hard to remove deserve extra scrutiny. External-facing changes are harder to reverse than internal ones.Also consider: what is the cost of not making this change? A serious recurring problem deserves more latitude than a theoretical future need.
Produce the report in the output format specified in .
