菜单
Convert an approved project brief or request into testable requirements, work items, acceptance criteria, edge cases, non-functional requirements, and traceability. Use before design or implementation when expected behavior is not fully verifiable.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | requirements-acceptance |
| description | Convert an approved project brief or request into testable requirements, work items, acceptance criteria, edge cases, non-functional requirements, and traceability. Use before design or implementation when expected behavior is not fully verifiable. |
| license | MIT |
Read ../.shared/operating-model.md and use the requirements template in ../.shared/artifact-templates.md.
Use for features, bugs, refactors with behavioral constraints, platform/infrastructure changes, migrations, API/data changes, security/reliability work, and multi-PR initiatives. Compress to a few criteria for small low-risk changes.
Expect a project brief or clear request. Inspect current behavior, tests, schemas/contracts, public APIs, accessibility/security/privacy guidance, service objectives, deployment constraints, compatibility commitments, issue/PR history, and relevant authoritative third-party docs.
REQ-* IDs for functional, non-functional, constraint, migration, and operational requirements where traceability helps.AC-* as observable outcomes with a verification method. Include positive, negative, boundary, permission, failure, retry/idempotency, concurrency, empty/large/old-data, and recovery cases as relevant.Requirements set, acceptance criteria, edge-case inventory, non-functional requirements, dependency/conflict log, traceability matrix, and readiness decision. Handoff to solution-design, or to delivery-planning for an already-established low-risk design.
Every must-have requirement is unambiguous enough to test; each has source/rationale and acceptance; material NFR/migration/accessibility/security/operations concerns are addressed or explicitly not applicable; unresolved blockers are visible.
Use first to route end-to-end, ambiguous, multi-phase, review, release, incident, or decommission work through the minimum sufficient project-delivery lifecycle when depth, state, or authority is unclear.
Close delivery by capturing outcomes, learning, technical debt, follow-up work, reusable decisions, and measurable process improvements in canonical project knowledge.
Coordinate delivery across authorized trackers, documents, meetings, calendars, messages, and operational systems while preserving canonical sources, exact targets, write authority, traceability, and read-after-write evidence.
Update canonical project knowledge for users, developers, operators, reviewers, releases, and future agents. Use for docs-only work or whenever a change affects behavior, interfaces, configuration, architecture, operations, migration, status, or release communication.
Prepare, validate, and—when explicitly authorized—execute integration, CI/CD, versioning, deployment, rollback, monitoring, post-release verification, and hotfix/change-management work.
Assess and improve security, privacy, risk, reliability, observability, supportability, and operational readiness across requirements, design, implementation, review, or release.