Product enables understanding of why the project exists and what it promises to whom, even without an initial conversation. It does not choose implementation technology, runtime structure, UI system, or delivery tasks.
Before performing this skill, references/communication.mdopen and apply it to natural language sent to the reader or saved in documents during the performance. This includes guidance sent when terminating at a gate.
Enter with valid conditions
Before starting actions for each target, references/project-gate.mdopen and product apply the conditions. Then
references/project-knowledge.md와 references/product-document.mdopen. If a readable
.devflow/index.mdalready exists, read it before selecting Product input.
If the current member's Sketch state specifies next_route로 product, before writing the file
references/sketch-handoff.mdopen and complete the landing contract together with the Product publication.
Enter Product when there is a new project brief, a project Sketch with conclusions ready to be reflected in Product, an open question that changes the current Product meaning, or a product judgment handed over by an ongoing Adopt.
Investigation and reconstruction of a maintained brownfield source without an internal Devflow foundation is handled by adopt.
However, if an ongoing Adopt has sent a product judgment here, do not send it back to Adopt again. Read the evidence indicated by the adoption state and handle only that judgment, and do not fix sources.md와 conflicts.md.
If additional investigation or experimentation is needed to obtain an answer and the question and context must be preserved beyond the current stewardship interval,
sketchroute to. Do not publish an incomplete canonical Product to store interviews that require multiple sessions.
Inquiry and review perspective
Product, like Dewey's inquiry, composes an incomplete request into a product problem connected to users, problems, and core promises. Individual cases and roles, like the hermeneutic circle, are cross-checked against the overall product description, and the current overall description is treated as an interpretation that can be revised with new clues. Only when important promises are difficult to hold together, Socrates' elenchus is used to reveal premises and consequences, and it is not used to refute or increase the number of questions.
Build current understanding first and ask only what is needed
Using the brief, user decisions, relevant project Sketch findings, evidence indicated by the adoption state, and existing Product and Domain canon, first compose the current product into a single description. Do not turn items in the Product document into survey questions or ask again about what is already known.
The mere fact that functions and roles are listed does not mean it has been decided which user's problem takes priority and what the core promise is. There is grounds only if the input directly states that problem or priority, or if interpretations other than the natural one with different purposes and responsibilities are excluded. If there is more than one such interpretation, do not pick one that seems plausible; instead explain the differences and then first ask the single highest-level question that divides them. Do not invent business rules or exclusions that the input does not state, and if they do not divide that fork, do not ask about them and leave them empty. While the priority problem and core promise have not been directly decided, do not ask about subordinate business rules that would vary depending on that choice. Before judging something to be a contradiction, first check whether there is a natural interpretation under which the user's explanation and examples hold together.
Product asks about product choices the user can answer now based on their own experience or intent. First check the grounds verifiable in the current conversation. Only when additional investigation or experimentation is needed and that context must be preserved until the next management-rights interval, send it to sketch. Product choices that cannot be decided by evidence are left to the user. If that choice remains undecided beyond the current conversation, do not publish an incomplete Product, but preserve it in sketch.
Questions include the current understanding, the points that are empty or hard to hold together, and what changes depending on the answer, in plain words. If multiple questions appear, handle first the one that changes the answers to the other questions.
According to this criterion, only just before actually asking for the user's explanation or binding choice, open
references/question-dialogue.mdand apply it to the question wording.
If an answer conflicts with an existing explanation, do not silently discard one side. Check whether the two meanings can actually hold together, and if not, leave it to the user to decide which promise to keep. If content the user cannot decide is essential to the product definition, do not publish the Product. If it is not necessary to consistently explain the current product, it may be left as an open product question with the current treatment and the conditions for deciding again.
If a judgment received from an ongoing adoption is handed off to another route, before leaving, replace the adoption state with one route that will take over that judgment and one scoped next action.
Do not ask about technology, file layout, components, database, test tools, visual style, or implementation order.
foundation publishing
In a new project, .devflow/project/product.md, the Domain business child that has actually passed the necessary Domain parent and common decomposition criteria, .devflow/index.mdconstitute a complete current document and then publish it. If the Domain parent is sufficient, do not create a child. When parallel comparison of roles, constituent units, Domains, and responsibilities is needed, a table may be used, but do not create fixed headings or empty sections.
index routes product boundary questions to Product, Domain business questions to the appropriate Domain parent, technical questions to an existing Architecture, and UI questions to an applicable Design. For active task recovery, expose only the immediate
team/<current-member>/sketches/*/state.md, adoption/state.md, work/*/state.md glob.
Explain that Architecture readiness is judged by a complete Product and project/architecture.md, and Design readiness is judged by whether Architecture applies and, if necessary, project/design.md. Do not create nonexistent Architecture or Design files as placeholders.
When changing an existing Product, verify together the affected users, existing promises, data and permission semantics, and Domain boundaries. Replace only the canonical Product and Domain documents whose current meaning has changed, and update the nearest parent index only when the question route has changed. If important rejected alternatives or revisit conditions are needed to keep the current direction, open references/decision-document.mdand create or replace one current decision document. Do not create one to leave behind the fact that work occurred or a copy of the current rules.
End at the next open question
Before publishing, reread the new document against the evidence for its availability. Check that the same facts are not repeated between Product and Domain, that technical or UI decisions are not mixed in, and that business rules, invariants, or exclusions not present in the evidence have not been added for the sake of document completeness.
The new foundation specifies the Product and Domain paths to read and routes to architecture. Active changes are sent back to directif there is no missing technical foundation decision. Judgments received from an in-progress adoption are routed to adoptaccording to the common gate's return contract after the answer is published to the canonical Product or Domain. Do not change state before publishing is complete.
Report the following.
게시한 경로:Canonical path created or replaced현재 제품 정의:The product's purpose, audience, and key promises구성:Roles, product units, Domains, and responsibilities that actually exist, ornoneRoute와 행동:One next route and one scoped action열린 항목:Only when there are product questions not currently decided and closing conditions
Do not write Architecture, Design, Work artifacts, implementation, adoption inventory, or verification verdicts.