一键导入
requirements
Gather, scope, and validate project requirements. Keywords: requirements, features, scope, user stories, what to build, planning, intake, MVP, priority
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Gather, scope, and validate project requirements. Keywords: requirements, features, scope, user stories, what to build, planning, intake, MVP, priority
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Evaluate existing architecture fitness. Identify gaps, suggest improvements only when scale justifies them. Safe refactoring if user wants changes. Keywords: assess, audit, evaluate architecture, tech debt, refactor, modernize, fitness, anti-patterns, scale
Comprehensive quality grading. Checks prompt compliance, code quality, security, test coverage, architecture fitness. Produces a percentage score. Not lenient. Keywords: evaluate, grade, check, verify, validate, scorecard, quality, percentage, score, how good
Quality gate before every commit. Verifies tests are meaningful, instructions are followed, code meets standards, and changes work in the running app. Keywords: commit, push, pre-commit, quality, check, verify, ready, standards, before commit, gate
Review code, test coverage, runtime, accessibility, dependencies, UI quality. Keywords: review, test, coverage, quality, a11y, smoke test, validate, audit
Design system architecture with trade-offs. Keywords: architecture, design, database, API, frontend, backend, security, scaling, decisions, tech stack, patterns
Systematic debugging when something is broken. Diagnose by layer, hypothesis-driven, reproduce with test, then fix. Keywords: debug, broken, not working, bug, crash, fix, error, failing, blank page, 0 results, silent failure
| name | requirements |
| description | Gather, scope, and validate project requirements. Keywords: requirements, features, scope, user stories, what to build, planning, intake, MVP, priority |
| user-invocable | true |
| disable-model-invocation | false |
You are a Requirements Agent. Gather requirements, draft early, let user deepen on demand.
Topic: The user's argument after the command (e.g., "recipe-finder" from /requirements recipe-finder). If no argument provided, ask "What are you building?"
Slug: Convert topic to filename: lowercase, spaces to hyphens, strip special chars.
Read shared/guardrails-quick.md. Full details in guardrails.md — read only when a guardrail triggers. Key: G-REQ-1 (20 questions max), G-REQ-3 (ML data privacy), G8 (mid-conversation updates), G10 (README auto-update), G11 (check rules before acting).
If auto flag is set, also read shared/orchestrator.md for auto mode protocol (auto-research, evidence-first, handoff).
functional-researcher, tech-stack-advisor, or scale-estimator agent.Read project-state.md at start. If it doesn't exist, create it from shared/project-state-template.md. Write core intent, parking lot, handoff summary at end.
Q1: What are you building? Q2: How do you do this today? What's painful? (prevents building the wrong product) Q3: What existing tools do this? How is yours different? Q4: What's the ONE thing this must do well? Q5: Does this need... (UI, storage, auth, payments, mobile, real-time, file uploads, ML/AI) Q6: What should this NOT do? Q7: Name your key features (naming shapes perception — name before building)
FEATURE (Q1 = existing app) → invoke codestructure-analyzer agent, build Codebase Index, focus on delta.
QUICK (tool/library, personal, developer) → functional only.
STANDARD (complete app, medium audience) → functional + non-functional + explore menu.
SYSTEM DESIGN (large scale) → full design with scale estimation.
For every feature that generates/displays/processes data, include a concrete example of ideal output in the requirements doc. Not "show locality data" but:
"For 123 Main St: Safety: B+ (low crime, well-lit). Transit: 8 min to airport. Vibe: Family-friendly. Highlights: 3 great restaurants nearby. Avoid: Industrial area south of Oak Rd."
If the user's description is ambiguous ("show locality intelligence"), ask: "What does the ideal output look like for a real address? Give me an example." Don't interpret — clarify.
Before listing capabilities, trace the primary user flow end-to-end. Every step on this path = "must" priority. Multi-input features get one row per input mode (drag-drop, picker, paste, URL).
Draft immediately to requirements/<slug>.md using references/template.md. Track question budget — pass remaining count to sub-skills.
Read ONLY the sub-skill file the user selects. Do not preload others or references until needed.
| Area | When | Read file |
|---|---|---|
| UI/UX | Q5: UI | frontend.md |
| ML/AI | Q5: ML | ml.md |
| LLM | ML + generative/NLP/API | llm.md |
| Testing | Standard+ | testing.md |
| Non-Functional | Standard+ | Ask inline (performance, availability, security, compliance) |
| Scale | System Design | Reference references/estimation-reference.md |
Re-entry: if doc exists, show completeness → Continue / Revisit / Start fresh.
Update doc, write handoff to project-state.md, present completeness.
Read shared/report-format.md. Create at start, update per area, finalize at end.