sketch

Narrowing one open question

Sketch preserves only the inquiry needed to bring one governing question to a decidable state. It can handle both an uncertain idea for a new project and a question blocking a change in an existing project, but it does not turn the conversation into an investigation archive or force a single analysis method.

Before performing this skill, references/communication.mdand apply it to natural language sent to readers or saved to documents during the performance. This includes guidance sent when exiting at a gate.

Enter only when the inquiry must continue

Before performing target-specific behavior, references/project-gate.mdand apply the sketch row. .devflow/index.mdIf it can be read, read it first, and follow only the project route relevant to the governing question.

Create a Sketch only when all three of the following conditions are true.

1. Before narrowing the open question, Product or delivery cannot safely determine the next outcome.
2. Evidence or a user decision is needed before implementation, and implementation is not the cheapest evidence for distinguishing between candidates.
3. The question, current evidence, or next action must be preserved beyond the current stewardship interval.

Otherwise, keep the discussion within the current conversation, send a clear project brief to product, send an actionable change to direct, and send learning that must be obtained through implementation to Direct shaping. The number of files, novelty, and the word "research" itself are not reasons to continue the inquiry.

When creating a new persistent Sketch or continuing one, references/project-knowledge.mdfirst.

If the answer establishes product meaning before a foundation exists, choose the project scope. If a current project decision is blocking one delivery outcome, choose the change scope. Do not merge unrelated questions just because they came from one conversation.

Inquiry and review perspective

Sketch, like Dewey's inquiry, turns vague uncertainty into one problem situation that blocks the next decision. Only when current evidence does not force one explanation, use Peirce's abduction to set up the minimum candidates meaningful for the decision, and do not fill a quota of candidates or treat hypotheses as facts. When distinguishing between candidates, as in Popper's critical test, first look for the cheapest observation that would change the current conclusion, but do not discard the entire product purpose because of a single failure.

Open a minimal recoverable artifact

S-short-label-<token>Create an opaque ID that is hard to collide with, such as , and verify that it is not in the current tree. .devflow/team/<current-member>/sketches/<artifact-id>/brief.md와 state.mdand every file uses a common routing header. This folder is the current member's personal exploration workspace. It does not default to exploring, reading, or taking over another member's Sketch. This boundary keeps intermediate questions and hypotheses from being collected as each other's input, but it does not restrict repository access permissions.

brief.mdmust explain the reason for exploration on its own. Write the project/change scope, one governing question, background and user intent, already confirmed facts, explicit non-scope, and the criteria at which the answer reaches a decidable state. Do not store conversations, chronology, proposed implementations, or general research plans.

state.mdis not a log but a single current snapshot that gets replaced. Follow this form.

next_route: sketch
next_action: <하나의 범위가 정해진 증거 수집 또는 결정 행동>
blockers: []
unresolved_findings:
  - question: <하나의 미해결 질문>
    destination: <product | architecture | design | direct>
    landing_condition: <흡수할 준비가 되게 하는 증거나 결정>

all four fields are required while the artifact exists. A finding remains in unresolved_findingsuntil absorbed into the designated canonical home where the conclusion belongs. landing_conditionbeing satisfied means it is ready to post, but that alone does not remove the item. A blocker is what prevents the next action, not the mere fact that the answer is not yet known. If you must switch to the same member's next role without finishing the current action, first replace the snapshot. Do not append attempts, conversations, progress, or previous routes. next_routespecifies the next Devflow role and does not change the member. Do not create a separate team/<member>/<artifact-id>.md note.

If the Sketch is the project's first entry point, also publish a small .devflow/index.md. Explain the project in one line, route open explorations with a scoped Sketch state glob, and expose only the team/<current-member>/sketches/*/state.md, adoption/state.md, work/*/state.md glob used for immediate recovery. State that the foundation is not ready until Product and Architecture, and Design where applicable, are complete. Do not duplicate the question's evidence in the index or enumerate active IDs. If the index already exists, modify it only when the question route or readiness statement actually changes.

Gather only evidence that changes the decision

Choose the cheapest evidence that can change the current decision. The method may be source inspection, a scoped experiment, external research, comparison, or user choice. The Sketch does not require a market analysis order, questionnaire, or fixed number of options. Distinguish observed facts, interpretations, open questions, and the conditions that resolve each question.

If every reader of the governing question needs the evidence, put it in brief.md. Only create findings/<concern>.mdwhen independent questions can be chosen from the brief alone before opening the body, and the avoided reading or write conflict outweighs the cost of a new route. A finding contains the question, relevant evidence, the distinction between observations and interpretations, important options and trade-offs, the current conclusion or unknown, and confirmation conditions. Do not repeat the destination, preserve a list of search results, or let it become a second brief.

Ask the user only about binding choices that cannot be decided by evidence. If the next evidence cannot be obtained, put the exact dependency in blockersand use next_route: user, and instead of fabricating a conclusion, write which answer resumes the Sketch.

Only immediately before actually asking for the user's explanation or binding choice according to this criterion, references/question-dialogue.mdand apply it to the question expression.

Reflect only confirmed conclusions in the canonical owner

Before disclosing a decidable conclusion, references/sketch-handoff.mdand follow the landing contract.

When a finding becomes decidable, express the conclusion in the destination's language rather than in investigative prose. The product meaning of project scope is mainly sent to productTechnical and UI findings are sent to architecture or designwhen the corresponding stage can absorb them. Answers for change scope send only delivery decisions to direct, and facts that remain true after the change are first sent to a single Product, Domain, Architecture, Design, or decision home.

After the next role closes the artifact, Git preserves the final history.

Return the current decision boundary

Return the following.

• 범위와 질문: project or changeand the governing question
• Artifact: The path of the Sketch created or updated, or, if the result was completed within the current conversation, none
• 증거와 결론: What was observed, the conclusion currently supported, what is not yet known
• Route와 행동: Exactly one next route and one scoped action
• 미검증 또는 차단: Missing evidence, binding user choices, and the resumption conditions for each

Do not create or modify Product, Domain, Architecture, Design, Work, adoption, implementation, or verification files. It is complete when the question can land directly in the current conversation, or has become a persistent Sketch that can be resumed from the brief and current snapshot alone without the original conversation.