메뉴
Review existing requirements or convert raw context into high-quality requirements for PRDs, specs, user stories, acceptance criteria, BRDs, FRDs, requirement catalogues, and stakeholder notes.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Improve, audit, simplify, rewrite, or migrate prompts, tool descriptions, agent instructions, and prompt stacks for GPT-5.6 Sol or the GPT-5.6 family. Use for outcome-first prompt design, autonomy boundaries, tool routing, PTC, grounding, verbosity, reasoning effort, and prompt evals.
Apply a deep, design-minded engineering workflow for complex work that needs careful planning, iteration, and simplification.
Use when preparing or running a Claude CLI agentic engineering review through claude -p for repository audits, architecture analysis, system design, security review, large refactors, specs, RFCs, or evidence-grounded long-form engineering analysis.
Use when preparing or running a ZCode GLM-5.2 agentic builder workflow through zcode --prompt for fast implementation, iterative code generation, focused fixes, and validation on an existing repository.
Apply adversarial opposite-analysis to plans, specs, architecture, code changes, and claims. Use when the user asks for adversarial review, opposing analysis, contrarian review, red-team reasoning, or Z.ai and MiniMax cross-checks through the Ralph MCP router.
Review and adjudicate Bugbot, Cursor, Seer, and similar automated PR feedback with local evidence before accepting, fixing, or dismissing findings.
| name | make-requirements-great |
| description | Review existing requirements or convert raw context into high-quality requirements for PRDs, specs, user stories, acceptance criteria, BRDs, FRDs, requirement catalogues, and stakeholder notes. |
| user-invocable | true |
| argument-hint | [requirements, PRD/spec text, stakeholder notes, or feature idea] |
Use this skill when the user mentions requirements, PRDs, specs, user stories, acceptance criteria, BRDs, FRDs, requirements quality, requirements traceability, requirements catalogues, or shares raw context that should become formal requirements.
This is a Codex-safe adaptation of the upstream make-requirements-great skill. It has no external command, model, deployment, credential, or network dependency.
Detect the input mode before doing anything else:
Do not impose a new format unless the user asks. Match the user's existing format where possible. If no format exists, write each requirement as a single clear sentence and add fields only when needed for owner, source, acceptance criteria, or traceability.
Always identify the level before auditing. A high-level requirement is not a defective low-level requirement.
If the intended level is ambiguous and the critique depends on that level, ask the user which level they intend. Do not silently default to solution-level.
High-level gaps that are really design decisions should go under Decisions for decomposition, not in the defect log. A real defect at high level is a defect at that level: unclear intent, contradiction, missing stakeholder, missing owner, stale scope, or untraceable value.
Default to not decomposing. Split a requirement only when the user asks, the requirement combines multiple intents at its own level, or the user confirms they wanted a lower level of detail.
Apply the characteristics as checks, not as vibes. Per-item characteristics apply to individual requirements. Set-level characteristics apply to the catalogue.
Can two competent readers independently reach different interpretations? Flag weasel words such as appropriate, suitable, reasonable, user-friendly, intuitive, efficient, fast, robust, scalable, secure, simple, flexible, optimized, high-quality, sufficient, as needed, where applicable, if necessary, may, might, could, and/or.
If a value is undecided, do not invent one. Write the best requirement possible and add an open question.
The target stakeholders should understand the requirement without a translator. Define domain terms, expand acronyms on first use, and keep sentences parseable in one pass.
Remove words that do not change meaning. Keep precision over brevity. The goal is the shortest expression that preserves every constraint.
A requirement is correct only when the relevant per-item and set-level characteristics pass and the owner agrees that it represents the actual need.
Write the test that would prove the requirement is met. The pass condition must be objective and measurable at the requirement's level.
Business-level testability can be a measurable outcome. Stakeholder-level testability can be an acceptance test that becomes concrete during design. Solution-level testability should be concrete now.
Scan for named technologies, UI controls, vendors, data structures, screens, and APIs. If the named thing is a design guess, restate the behavior. If it is a real external constraint, label it as such.
A named accountable person should confirm correctness, sign off against delivery, and resolve disputes. Do not invent owners. If the owner is missing, flag it.
Every requirement should be in scope and materially advance the business need. Trace it to the problem statement, business case, regulation, stakeholder request, or other source.
Check feasibility against known budget, time, team skills, legal, technology, and operational constraints. If uncertain, mark feasibility pending and list what evidence is needed.
Across the catalogue, find duplicates and near-duplicates. Merge true duplicates. Rewrite near-duplicates so the distinction is explicit.
Each requirement should express one intent at its own level. Split requirements that combine different intents, owners, or tests.
Look for internal contradiction, contradiction between requirements, and terminology drift. Define canonical terms when multiple names refer to the same concept.
Requirements should follow the agreed template, style, fields, and level of detail. If no standard exists, propose one based on the dominant existing format.
Requirements should have a review date or version signal. Anything older than the latest scope change needs review.
The catalogue should be easy to change: stable IDs, logical grouping, version history, and cross-references by ID rather than section number.
Each requirement should answer both: where did this come from, and where will it be verified or implemented? Untraceable requirements are candidates for owner review, not automatic deletion.
Classify requirements by type where useful: business, user, functional, non-functional, interface, data, security, performance, reliability, usability, regulatory, or constraint. Thin or missing categories may be findings.
Completeness is never fully provable. Show the techniques used: category checklist, CRUD check for key entities, lifecycle check for roles and entities, and reviewer coverage where available.
Return three artifacts unless the user asks for another shape:
For high-level requirements, add Decisions for decomposition when details belong to later design rather than the current requirement level.
If the user asks for a quick check, fast triage, or what jumps out, skip the full log. Surface the highest-impact defects, name the violated characteristic, and give one rewrite per top defect.
