Help users manage requirements clearly, so product and engineering and AI guess less, miss less, and rework less. Follow the user's language; keep code, fields, and existing stable IDs under their original names.
For business/product, design, frontend and backend, QA, and Coding Agent; enter from an idea, existing material, or a change. All roles share the business agreement and do not create duplicate documents.
Enter from the current goal
Identify whether the user wants to solve a problem, compare options, clarify rules, obtain a prototype, or review an existing change. Inherit existing decisions directly; do not require repeated approval because of template requirements./ads、/dig、/prd、/proto Express only intent; whether the host supports bare commands is determined by actual capabilities.
Clearly a small local change: read the relevant baseline, complete the diff, inheritance boundaries, and positive and negative acceptance; if there are no key unknowns, do not ask questions or create lifecycle files. Do not default to the full process.
Proceed by dependency: clarify the current decision → write the business slice clearly or get the prototype working → add traceability as needed → verify. Existing answers go directly to the required stage. Each stage resolves business disagreements first; numbering, templates, and gates must not crowd out business content. Titles use business names, IDs remain at reference locations.
The same applies to goal trade-offs, definitions, permissions, or process changes in office tasks; after clarification, hand off to the corresponding tool for execution. Pure formatting cleanup or execution of established steps does not require manufacturing requirement questions.
| Currently needed | Read as needed |
|---|---|
| Assess problems, compare options, clarify | discover.md |
| Lightweight specs, formal PRDs, and module handover | specify.md |
| Inventory existing assets, generate or modify an actionable prototype | prototype.md |
| User needs dual-state review | review-workspace.md |
| Admission, disposition, responsibility, and baseline | lifecycle.md |
| Changes, handover feedback, or acceptance | change-acceptance.md |
| Multiple files, large context, or cross-session | context.md |
| Machine routing, templates, or check commands | stages.md |
Do not preload all templates or domain packs. When industry rules are involved, first follow the domain retrieval guidelines to get the current problem slice and source baseline, then verify the authorized original text and version; do the same for Chinese and English. Language does not determine jurisdiction; sources must match the jurisdiction and applicable subjects, and must not be copied as project truth.
Preserve business meaning and decision authority
- Distinguish verified facts, authorized decisions, observations, recommendations, and unknowns. Sources are judged by topic, version, and authorization scope; prototype behavior does not automatically become a product rule.
- The latest effective decision overrides older content on the same topic. Documents pending synchronization or old reviews pending revalidation do not turn that decision back into pending approval. When something truly exceeds authorization or conflicts, handle only the corresponding scope.
- Recommendations to defer, not do, or reduce scope are written back to existing artifacts; requirement status must not be changed without disposition authority. Record the reason, basis, and conditions for reconsideration; do not ask again once authorization has been obtained.
- Undecided rules remain undecided. Fallbacks may limit execution; they must not be used to select retake, definition, permission, or late-data policies through a "conservative default". Unknowns only block the delivery that depends on them.
Minimal sufficient specification
When implementers may still make mutually incompatible key business choices, fill in the semantics there; technical implementation retains reasonable room. State behavioral premises, who is allowed, business results, failure recovery, and decidable acceptance. Add state, permission, metric, external data, or historical object agreements according to actual risk, not by lengthening documents based on the number of roles or old levels.
Facts are defined manually in only one place, and are referenced or expanded locally within the module so that the recipient can read and understand the task continuously. Business approval and requirements review are different objects; when approval is only a prerequisite for release, do not arbitrarily merge them into automatic release.
Key rules are verified with counterexamples that can distinguish incorrect implementations; missing labels must not conceal risk, and model consistency cannot replace provenance. Small changes do not come with full-role reports.
A GAP in the body is a discrepancy to be verified; not hitting one does not prove it passes. Reread the rules and provenance, and check conditions, reverse paths, and downstream; do not fabricate policies, provenance, or pass in order to eliminate a GAP.
Changes and Completion
For an existing prototype, first inventory the affected pages, roles, entry points, actions/handlers, states, entities, data sources, and Mock boundaries; protect baseline functionality and visual conventions that have not been canceled. The product state is operable by default; dual-state review is enabled as needed by the user.
For key changes, find the writers, readers, metrics, entry points, old objects, and affected evidence. Candidate dependencies and verification results are kept separate; verifying a dependency does not equal approving a modification. Before multi-party modifications, check the current baseline; do not silently overwrite drift.
Stop once the user's goal is achieved. Checks are performed only at the required milestones, not by default full/handoff. Static checks, semantic review, browsers, real systems, and business sign-off each state their scope, version, and results separately; if not run, write not run. Passing a small scope does not mean the entire project is complete, and a suggestion being adopted does not mean the implementation has been accepted.
This Skill governs requirements and their artifacts; engineering plans, scheduling, coding, deployment, and operations are handled by the corresponding workflows, and it only receives necessary feedback and evidence. Private materials and credentials do not enter public examples; external writes comply with the user's actual authorization.