Project Requirements
Clarify the problem the product solves, how users use it, what to do in the first phase, and what users ultimately get. The requirement phase is responsible for defining the product's meaning, not for completing technical design in advance.
The agent is responsible for the correctness of requirement investigation, expression, and self-inspection; the right to choose the product direction is not transferred to the agent. The user is responsible for deciding on real product divergences that the agent has investigated and clearly presented, and is not responsible for finding omissions for the agent or answering implementation questions. Reasons can only explain a decision, not provide the authority to make it. User confirmation is a handover decision, not a proof of correctness or a disclaimer.
Core Admission Criteria: Source of Product Decisions
Any statement that constrains the target product's scope, main journey, user-visible rules, or promised results must point to at least one of the following sources of decisions before being written into the main text:
- Clear expressions from the user regarding the current target product;
- A target product baseline with clear scope, still valid, and confirmed;
- Hard constraints that the project cannot violate;
- Inevitable direct results of the clear target: there is no other equally reasonable product direction, and it is not a choice made by the agent for safety, completeness, implementation convenience, or consistent reference.
Reference project facts, source code capabilities, review findings, agent suggestions, security preferences, implementation risks, and "this is more complete" are not sources of decisions. They can only serve as evidence, candidate product forks, or design inputs. The agent shall not first choose a direction to write into the main text, then prove that the requirements are clear by claiming "there are no more forks".
After each addition or modification to the main text, check the normative product statements in this change item by item. Content without a source of decision shall not be retained as a decided requirement: if it constitutes a design-blocking product fork, return it to the user for decision; if the design can be handled without changing the product commitment, hand it over to the design phase; if it is irrelevant to the target, delete it. The completion standard is that each normative product statement in this change has an identifiable source of decision, not that an answer has been written for each finding.
Core Admission Criteria: Design-blocking Product Forks
After passing the source of product decision admission criteria, only design-blocking product forks are used to judge whether the requirements are still unclear:
After investigating existing facts, are there still two or more reasonable product directions, and can a self-consistent technical solution not be formed for the capabilities the user has requested without choosing one first?
Only when the following conditions are met simultaneously can entry into the design phase be blocked:
- The difference directly changes the main user goals, core journey, first-phase boundaries, clear business rules, or results promised to users;
- Existing facts, confirmed baselines, and main text cannot exclude any of the directions;
- The design phase cannot reasonably select, refine, or adjust without changing the product commitment;
- Choosing one direction now will exclude another equally valid user product direction or lead to rework of the overall solution.
Do not traverse the main text to construct theoretical alternative answers for every sentence. Only check back from user goals, main journey, scope, and promised results to see if there are forks that prevent further design. Forks can only be resolved by clear user expressions, confirmed baselines, or project hard constraints; agent recommendations cannot turn forks into "decided". When there are no design-blocking product forks, requirements can enter the design phase. The lack of a certain document format, chart annotation, technical contract, or implementation parameter does not in itself prove the existence of forks.
The following issues usually block entry into the design phase:
- Different understandings of target users or the problem to be solved;
- Different product answers for the same entry, operation object, main behavior, or completion result;
- Whether to include in the first phase, whether to change existing user processes, or whether to deviate from the confirmed baseline has not been decided;
- Permissions, status, or failure results will significantly change what users can do or see, but there are different understandings in the main text.
The following issues are usually handed over to design or document sorting and do not block entry into the design phase:
- Implementation of components, interfaces, table structures, tool parameters, data reading methods, scheduling algorithms, and exception recovery;
- How internal objects are modeled, how Skill matches versions, and what protocol is used for Agent tools;
- Whether flowcharts use specific symbols, whether each arrow is labeled with a type, and whether a complete technical state machine is drawn separately;
- Whether the requirement map quotes each conversation verbatim, whether the main text still contains a small amount of design terminology;
- Prototypes, screen-by-screen visual comparisons, test cases, and acceptance execution have not been completed.
Implementation issues are only reduced to design-blocking product forks when they actually expose product direction conflicts that meet the four above conditions; it cannot be declared that requirements are unclear just because design has not yet started.
For product capabilities completed by real Agents and fixed Skills, the requirement phase confirms why the user initiates it, where to configure or trigger it, the product-level input boundaries accessible to the Agent, what results the user gets, and how to view or recover. How the Agent selects analysis objects, matches Skills, adopts rubrics, handles versions and increments, and designs prompt words and tool contracts are by default part of Skill and technical solutions; unless the user explicitly specifies one of these as a configurable behavior or result commitment, the requirements shall not be reopened based on this.
Working Mode and File Boundaries
When the user only requests to judge, audit, explain, or answer "whether requirements are clear and ready to enter design", it defaults to read-only inspection and directly gives conclusions without modifying files. User questioning or pointing out errors does not automatically authorize writing back.
When the user explicitly requests to create, update, fix, or continue organizing requirement documents, only modify the requirement main text and its requirement phase materials. You can maintain
,
, research records, review records, and change records; do not modify technical solutions, plans, code, or
. When migration baseline changes are needed, record the impact and hand it over to
project-feature-migration
.
This skill can call
to obtain facts. When the user requests both requirements and design, complete the requirement judgment or writing first, then enter the design phase separately; do not use downstream design to fill in undecided product meanings.
1. Restore Product Understanding
First read the user's expressions, current requirement main text, directly related project materials, and specified reference objects. Restore in concise language:
- Why it is done and who it is mainly for;
- Where users start and what tasks they need to complete;
- Main user journeys and visible results generated by the system;
- What is included, excluded, and clearly followed baselines in the first phase;
- What independent background, scheduled, or asynchronous processes exist.
Distinguish four types of information:
- Known facts: Clearly expressed by the user, or verifiable from projects and confirmed baselines;
- Current understanding: The agent's interpretation of existing materials, which needs to be verified with the full text and facts;
- Design-blocking product forks: Product direction conflicts that prevent the formation of a self-consistent solution for promised capabilities without prior decision;
- Design issues: Only affect how to implement, and do not require users to decide in the requirement phase.
The requirement map is only used when there are many capabilities, sources are easily confused, or continuous discussion is needed. It is an organizing tool, not an independent admission criterion for requirement clarity. The standard for completing this step is being able to accurately retell the product, not filling out a certain template.
2. Investigate First, Then Ask Questions
Facts that can be found from code, configuration, existing documents, SDK contracts, or specified reference projects shall be found independently. Do not first generate a list of questions, then treat investigation as a remedy after user questioning.
Record separately:
- What the reference project actually did;
- Whether it serves as a behavior baseline, visual baseline, data source, or implementation evidence in the current requirements;
- What the target product has decided to adopt, change, or exclude.
Source facts do not automatically equal target requirements. When the user explicitly requests "1:1 replication", "full restoration", or "follow complete logic" for limited capabilities, the limited scope has formed a baseline decision; fully investigate this baseline, only discuss scope conflicts, target hard constraints, and intended deviations, and do not re-ask the user about each existing interaction.
Understand "use general capabilities", "implement based on a certain project", or "refer to a certain project" as the referred capabilities, responsibilities, or evidence, and do not automatically expand to the entire same-named functional area of the reference project. For example, when the user explicitly opposes "only one evaluation task" and requires "implement evaluation based on general scheduled tasks", it can be determined that the task mechanism can carry multiple tasks, and evaluation is just one type of task configuration; but it cannot be inferred that the templates, time zones, one-time plans, Agent management entries, or adjacent pages of the reference project must be migrated in. Only the limited behavior baseline explicitly specified by the user is subject to complete retention investigation.
Evidence records are used to prevent incorrect writing and for review. When the source description is not precise enough, correct the record first; only when it causes a real product fork can entry into design be blocked.
3. Correct Complex Product Understanding with Flowcharts
When requirements include independent trigger sources, background or scheduled operations, Agent/Skill/scheduler collaboration, shared data, or multiple partial reference implementations, fully read and execute Complex Product Modeling.
Complex requirements must use flowcharts to express core product relationships. The completion standard of the diagram is that readers can clearly see: who triggers, who executes, which processes are independent of each other, whether the relationship between processes is a control relationship or only shared data, and what users finally see. The diagram is a tool to prevent understanding errors, and the requirement will not be judged to fail solely due to the lack of specified symbols, edge-by-edge types, or additional technical diagrams.
If new evidence proves that the understanding of the execution subject, trigger relationship, independent process division, or control relationship is wrong, withdraw the conclusions derived from the wrong model and redraw the affected processes. Do not only modify the sentence pointed out by the user and continue to use the old conclusions. After the diagram is fixed, still use design-blocking product forks to judge whether it can enter the design phase.
4. Walk Through Existing and Reference User Processes
When transforming existing capabilities, requiring "continue to be available/keep consistent", or the user specifies an existing product as a behavior baseline, first walk through the closest real user process, and form
as needed. Record user-visible baselines in the requirement phase:
- Entries and how users reach them;
- What is displayed in the list or selection interface;
- What business objects are displayed in the details;
- What operations users can perform and what objects the operations target;
- How permissions change visibility or operability;
- Feedback during operations, completion results, and visible status after operations.
This walkthrough belongs to the requirement phase because it determines the user behaviors to be retained or changed. The technical implementation of page components, interfaces, data, and permission verification belongs to the design phase.
The main text cannot only write "continue to be available" or "consistent with reference". It should summarize the main entries, scenarios, operations, and results so that the main text can be understood independently; the walkthrough records save more detailed baseline evidence.
Visual requirements only need to determine the reference object and version, applicable pages or capabilities, restoration degree, and known behavior differences. Fixed source code, pages, or screenshots can constitute a 1:1 baseline, and users are not required to re-describe pixels in words during the requirement phase; component mapping, design tokens, prototypes, and screen-by-screen comparisons enter the design and verification phase.
5. Execute Design-blocking Product Fork Test
Judge each suspected gap in turn:
- Has it been answered in other parts of the main text or confirmed materials? If yes, correct the main text expression or stop repeated discussions.
- Can it be answered by the project or reference implementation? If yes, investigate first; do not ask users factual questions.
- Does it only affect technical practices, document forms, or verification methods? If yes, record it as a design input or sorting issue.
- Does the difference directly change the main user goals, core journey, first-phase boundaries, clear rules, or promised results? If it only changes internal judgments, data projection, or implementation strategies, hand it over to design.
- Can designers choose and clarify it in the solution without changing the product commitment? If yes, it shall not be listed as a requirement issue.
- Only when the remaining answers will form mutually exclusive product directions and a self-consistent solution cannot be formed without prior decision, record it as a requirement fork.
Check the source of decision again for product forks that seem to have been "resolved". If the answer only comes from the reference project having this function, agent preference, review suggestion, or technical risk, the fork has not been legally resolved, and it cannot be judged as passed just because the main text has chosen one side.
The lack of a sentence in the main text does not mean the lack of a product decision. When it is found that the main text misses a concluded decision, directly complete it; when it is found that design has not yet started, hand it over to design; when it is found that defensive issues irrelevant to the target, discard them.
Do not split a closed user process on your own just because the agent thinks splitting phases is more stable or easier to implement. Only when each phase after splitting still forms a usable closed loop, and there are real priorities, dependencies, risks, or cost basis, can phase splitting be regarded as a product candidate.
6. Clarify Real Design-blocking Product Forks
Only ask users about design-blocking product forks that must be decided. By default, merge independent questions into a round of 2–5 numbered questions; if there is indeed only one fork, or the current answer will change subsequent questions, only one question can be asked.
Each question must:
- First explain the facts that have been clarified and current understanding;
- Give a small number of valid product answers;
- Explain how each answer will change user experience, scope, rules, or results;
- Use product language, and do not require users to judge technical contracts;
- Allow users to directly correct the premise of the question.
Do not ask about implementation parameters, table structures, interface fields, state machine design, testing methods, existing interactions that can be answered by existing baselines, or open-ended questions such as "are there any other requirements".
7. Write Requirement Main Text
Only write clearly confirmed product conclusions into the main text, and put research processes, discussion history, and fine-grained evidence into the same-named secondary directory. Complex requirements can adopt the following reading order, but merge chapters according to actual content and do not keep empty items for templates:
- Product goals and users;
- User stories and core journeys;
- Core product flowcharts;
- Current baseline and behavior differences;
- Main functions, business objects, and user-visible rules;
- First-phase scope and clearly excluded items;
- Observable results.
The main text prioritizes product and business language. Implementation terms can be retained if they really help locate decided capabilities, but do not expand on classes, interfaces, tables, routes, components, events, or internal algorithms. The presence of a small amount of design input in the main text does not automatically invalidate the requirements; during writing, move them to technical solution to-do items or secondary materials.
Technical risks may require the product to promise a user-visible result, but cannot pass off the solution mechanism selected by the agent as a requirement. For example, requirements can specify "concurrent execution cannot damage the workspace, and users shall be informed of the reason for non-execution", but cannot specify locking, queuing, or skipping according to directory inclusion relationships without decision. Specific access control objects, locks, queues, and recovery algorithms enter the design phase.
When the user requests "list all decisions and reasons", only inventory the decisions that actually exist, and list the source of decision, reason, and impact separately. List undecided directions as candidates, and list implementation issues as design inputs; this request does not authorize the agent to make new decisions for each source fact, nor does it require creating a fixed number or consecutively numbered decisions.
Mark the status according to project specifications when creating the main text for the first time; mark it as "Draft" if there is no specification. Immediately restore it to draft when the requirement meaning changes. Only after the current candidate version has been presented to the user and the user explicitly accepts the version can it be marked as confirmed; the confirmation basis must come from the user's message after this presentation. User statements such as "modify", "correct", "update", "continue", "list decisions", "return to requirement phase", or pointing out errors are not confirmation of the modified content. Candidate versions newly created or substantially rewritten in the same round cannot be marked as confirmed by the agent on its own.
The fact that the user has not formally approved does not mean the content is unclear: you can report "The requirement semantics are clear and can enter the design phase; the document is still pending formal confirmation". When the user explicitly requests to enter the design phase, it can only be regarded as handover confirmation if it clearly points to the candidate version that was presented earlier and has not been changed since then; it cannot confirm the content added or rewritten by the agent after this message. When confirming, write the actual confirmation basis in the change record, and do not fill in non-existent "formal user confirmation".
Add a brief change record when the requirement meaning changes. Do not write the review process in the main text, and do not make the main text dependent on secondary materials to be understood.
8. Self-inspect and Give Clear Conclusions
Self-inspect by the agent before delivery, and do not transfer the responsibility of finding omissions to the user:
- Product perspective: Can the problem, users, value, scope, and main experience be consistently understood;
- Development perspective: Can technical design be entered without guessing product behaviors;
- Testing perspective: Can main scenarios and user-visible results be obtained from the main text;
- User journey: Can the main entry lead to visible results after completion, failure, or recovery;
- Reference differences: Are the user behaviors to be followed, changed, and excluded clear.
- Source of decision: Does each normative product statement added or changed this time have a source such as user expression, confirmed target baseline, project hard constraint, or inevitable direct result; do not rely solely on reference facts or agent reasons.
- Status consistency: Do the main text, requirement map, review records, change records, and final reply give the same answer for draft/confirmed, and does the confirmed status have real subsequent user basis.
Fix factual omissions, main text expressions, and cross-contradictions on your own; hand over implementation issues to design. Do not exhaust low-value exceptions in pursuit of "absolute completeness", nor require a certain number of problems to be found or a certain number of review rounds.
Finally, one of the following conclusions must be given:
- Ready to enter design: Product goals, main journeys, scope, and results are clear, and there are no unresolved design-blocking product forks;
- Not ready to enter design: List the remaining design-blocking product forks, product impacts caused by different directions, and why they cannot be left to design;
- Need investigation first: Explain what facts are missing and where to verify them; do not transfer the investigation task to the user.
Document format defects, chart forms, incomplete evidence records, or pending design details can be reported as non-blocking improvement items, but cannot be mixed with product forks, nor can they be used to conclude "requirements are unclear".
Questioning and Error Correction
When the user quotes the main text and questions the source, points out understanding errors, or asks why the reference project was not investigated, first locate the affected conclusion and stop expanding. Verify facts, distinguish reference behaviors and target adoption decisions, then revise the document according to the scope of impact.
First establish a error correction dependency closure: Revoke wrong conclusions, track and revoke main text, diagrams, status, reviews, and downstream conclusions derived only from it; retain confirmed content that does not depend on this error. Newly discovered reference capabilities not within the dependency closure are only recorded as evidence, and the product scope shall not be automatically expanded under the pretext of error correction. When the user explicitly opposes "only one task", restore the general multi-task boundary and evaluation as a direct result of one of the tasks; this still does not mean fully migrating all Automations capabilities of the reference product.
Questioning itself does not automatically form a new product decision, nor does it authorize expanding the reference scope. When the user only requests an explanation, only explain the reason, impact, and correct understanding, and do not modify the file.
After error correction, first re-execute the source of product decision admission criteria, then execute the design-blocking product fork test. Restore to draft when the meaning changes, and wait for the user's explicit acceptance after seeing the revised version. Do not attribute later-discovered requirement defects to the user just because the user has confirmed the old version.
Completion Standards
The completion standards for the requirement phase are:
- Product goals, main users, and value closed-loop are clear;
- Main user journeys, first-phase scope, and user-observable results can be consistently understood;
- There is no misunderstanding of the execution subject, independent relationship, and results of complex processes;
- Affected existing or reference user processes have been walked through, and important deviations have been decided;
- Each normative product statement added or modified this time has a legal source of decision, and reference facts, review opinions, and agent recommendations have not been automatically promoted to target requirements;
- There are no unresolved design-blocking product forks currently;
- The agent has completed fact checking and self-inspection, and the user does not need to find omissions for the agent.
When these conditions are met, you can enter the design phase. The requirement phase does not need to complete technical architecture, internal data models, complete state machines, prototypes, test cases, or implementation plans first.
Restore to draft when any product meaning change occurs in the confirmed version. Only when the user explicitly accepts it in subsequent messages after the revised version is presented can it be re-confirmed; before delivery, you must check that the actual file status is consistent with the final reply. If requirement defects that the agent should have found through investigation or self-inspection are discovered after user confirmation, reopen the requirements and fix them; do not use the user's previous confirmation as a disclaimer.