clarify-demand
Scannednpx machina-cli add skill hardness1020/VibeFlow/clarify-demand --openclawclarify-demand
Conversational demand clarification and feasibility research before formal work item registration.
Purpose
This skill helps users go from a vague idea to a concrete work item registration. It runs before /manage-work register to ensure the right track, scope, and description are chosen.
Works on any branch (including main).
4-Phase Workflow
Phase 1: Demand Clarification
Ask the user to clarify the following (skip items they've already provided):
- Problem — What problem are you solving? What's broken or missing?
- Users — Who benefits from this? (end users, developers, ops, etc.)
- Done Criteria — How will you know it's done? What does success look like?
- Constraints — Any technical, time, or compatibility constraints?
- Scope Signal — Is this a bug fix, a single feature, a multi-component change, or a system-level change?
Keep the conversation natural. Ask follow-up questions if answers are vague. One or two rounds is usually enough.
Phase 2: Feasibility Research
Delegate to the codebase-analyst agent for read-only codebase analysis:
- Does existing code support this, or is new infrastructure needed?
- What files/modules would be affected?
- Are there existing patterns to follow?
- What are the risks (high coupling, missing tests, architectural debt)?
Skip this phase for obvious Micro/Small items where the scope is clear and the change is localized.
Phase 3: Synthesis
Produce an Intake Brief (displayed in conversation, not persisted to disk):
## Intake Brief
**Problem**: [1-2 sentences]
**Users**: [who benefits]
**Feasibility**: [summary from Phase 2, or "Skipped — scope is clear"]
**Complexity**: [Low / Medium / High]
**Recommended Track**: [Micro / Small / Medium / Large]
**Rationale**: [why this track]
**Suggested Description**: "<description for register command>"
**Suggested ID**: <numeric ID>
Phase 4: Handoff
Present the Intake Brief to the user. If they confirm:
/manage-work register "<description>" <ID> <track>
If they want changes, loop back to the relevant phase.
Guidelines
- Ephemeral output: The Intake Brief lives in the conversation only — no files are written.
- Bias toward smaller tracks: When in doubt, recommend Small over Medium. Users can always upgrade.
- Don't over-research: Phase 2 should take 1-2 minutes, not 10. Quick scan, not deep dive.
- Natural language: This is a conversation, not a form. Adapt to the user's communication style.
Source
git clone https://github.com/hardness1020/VibeFlow/blob/main/.claude/skills/clarify-demand/SKILL.mdView on GitHub Overview
clarify-demand guides users from a vague idea to a concrete work item by clarifying the problem, users, success criteria, constraints, and scope through a natural conversation. It runs before /manage-work register to ensure the right track and description, and works on any branch, including main.
How This Skill Works
The agent conducts Phase 1 questions to define Problem, Users, Done Criteria, Constraints, and Scope. Phase 2 delegates read-only feasibility analysis to the codebase-analyst to assess existing support, affected files, and risks. Phase 3 synthesizes an Intake Brief with recommended track and description, and Phase 4 handoffs for registration if the user approves.
When to Use It
- When a feature idea is vague and you need a precise work item before registering it.
- When you need a feasibility check against the current codebase before investing work.
- When you must classify the change as a bug fix, a single feature, a multi-component change, or a system-level change.
- When you want to define success criteria and constraints before starting work.
- When deciding the appropriate registration track (Micro/Small/Medium/Large) for /manage-work.
Quick Start
- Step 1: Engage in Phase 1 to clarify Problem, Users, Done Criteria, Constraints, and Scope.
- Step 2: If needed, trigger Phase 2 feasibility with codebase-analyst, or skip for obvious micro items.
- Step 3: Present the Intake Brief; if approved, proceed with /manage-work register using the suggested description and ID.
Best Practices
- Ask targeted, follow-up questions to reach specific answers within 1-2 rounds.
- Skip Phase 2 for obvious micro/small items with localized scope.
- Keep the Intake Brief concise and display it in conversation (ephemeral output).
- Use natural language and adapt to the user’s communication style.
- Provide a clear Suggested Description and ID to speed up the registration process.
Example Use Cases
- Clarifying a new dashboard filter feature requested by users and outlining problem, users, and success criteria.
- Evaluating the feasibility of adding a micro-feature in an isolated component without disrupting others.
- Turning a vague bug report into a scoped work item with defined done criteria.
- Assessing a multi-service change to determine required track and potential risks.
- Preparing an intake brief for a small system-wide change and deciding on a micro/small track.
