القائمة
Use when reviewing a draft or existing blueprint for quality — missing scenarios, terminology gaps, unclear requirements. Convenes the review panel for a structured debate.
التثبيت باستخدام 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 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.
Use when creating a new blueprint — generates the full directory structure with placeholder files and inline hints for each section.
| name | review |
| description | Use when reviewing a draft or existing blueprint for quality — missing scenarios, terminology gaps, unclear requirements. Convenes the review panel for a structured debate. |
Convene the review panel on a draft or existing blueprint to find rough edges, missing coverage, terminology conflicts and quality problems. For proposals to change the described system, use propose instead. For systematic checklist audit without debate, use audit.
Read the full blueprint. Evaluate against clarity (can any team member understand exactly how the system works?) and completeness (does it cover flows, states, rules and vocabulary someone needs to work confidently?).
Simulate the review panel from . Follow the debate protocol: present, respond, rebut, synthesise, verdict. Every panellist weighs in on every item.
Default disposition: fix the problem if a good fix exists. Burden of proof is on inaction, not on change.
For each item, state: what the problem is (quote the section), where it appears, why it matters, and a candidate fix.
All key terms defined? Each used consistently? Two terms for the same concept, or one term for two things? Every actor has at least one scenario? Error paths documented? Every user story has a delivering scenario? Every entity has definition, states, named transitions? All relationships captured? Implicit states hiding in booleans? Testable? Business rules sourced? Non-functional requirements specific with thresholds? Describes behaviour or implementation? Flag databases, endpoints, UI components, libraries, architecture patterns. Questions have owners and deadlines? Decision log has rationale? Decisions embedded in requirements that should be in the log?Produce the report in the output format specified in .
