- name
- decompose-with-user
- description
- Work with the user in two modes: understand existing work or decompose a goal into criteria and a specification. Use for interviews, shared analysis, and task shaping, with a persistent decision log and ADRs for coding work.
# Decompose with the user
Read [the shared guidance](references/principles.md), then the mode that fits the request:
- **Understand existing work:** [mode guidance](references/modes/understand.md).
- **Decompose proposed work into criteria:** [mode guidance](references/modes/decompose.md).
Use both when needed, keeping findings about the present distinct from proposals for change. Each mode links the relevant templates. Keep a decision/interview log by default; coding work produces specifications and ADRs.
Start from the conversation already available. Explore collaboratively: contribute hypotheses, concrete examples, sketches, options, and informed recommendations rather than conducting a strict interview. Ask manageable questions where answers would change the work, leaving room to reject the framing. Use the available question interface where appropriate.
Find retrievable facts yourself. Consult the user before settling consequential choices about direction, scope, priorities, architecture, or success. Do not ask again about decisions already agreed or expressly delegated. Make minor decisions within your authority and document them too, grouped briefly where useful. Let the exploration reshape the problem and return to the larger goal when detail takes over.
Keep the interview/decision log as the conversation develops, preserving important answers and brief reasons. In understanding mode, separate the user's account from observations and inferred explanations. In decomposition mode, turn agreed outcomes into useful criteria and a specification. Coding work includes ADRs. Adapt the supplied templates to the repository and consult relevant available thinking or specification skills.
Stop at the level the user needs. A draft with explicit questions can be useful; do not force every decision to closure or turn conceptual discussion into implementation.
GitHub에서 보기