define

Files (3)

• SKILL.md
• devils-advocate-review.md · resources/
• feature-brief-template.md · resources/

SKILL.md (first lines)

# Define

This is a human-facing skill.

Use it when the user wants to think through what to build next before asking Darwin to implement it.

## Purpose

Turn a rough feature idea into a clear feature document that is worth building.

The document should explain:

- what problem is being solved
- who it is for
- what success looks like
- what constraints matter
- what should not be built yet

## Dependencies

- `using-darwin`
- `clarifying-intent`
- `debrief-and-learn`
- `skills/define/resources/devils-advocate-review.md`
- `skills/define/resources/feature-brief-template.md`

## Clarification Rule

Ask at most 3 clarifying questions before presenting a defined direction.

Questions should focus on:

- purpose
- audience
- constraints
- success criteria

## Workflow

1. Use `clarifying-intent` internally to resolve the real goal, constraints, and success criteria.
2. Explore 1-3 plausible directions only if they materially change the product decision.
3. Run the devil's-advocate review resource to pressure-test the candidate direction.
4. Write the result as a saved feature document in `docs/features/` using the feature-brief template.
5. Run a collaborative debrief with the operator about the quality of the feature definition and the shaping workflow.
6. Canonize any clear Darwin improvement immediately when it belongs in a skill, prompt, or resource.
7. End with the next best step: build now, research more, or reshape scope.

## Debrief Rule

After the feature document is written, ask the operator:

- whether the problem is now framed correctly
- whether the success criteria are clear enough
- whether the document feels useful enough to build from
- what Darwin should improve in `define` or its nested resources

Use `debrief-and-learn` internally to extract the lesson and patch Darwin immediately when the improvement is clear and small.

## Output To The User

Keep the interaction simple:

- a few high-value questions
- a concise recommended direction
- a saved feature document in `docs/features/`
- a small set of concrete open questions only if they matter

## Guardrails

- Do not turn this into open-ended ideation with no decision.
- Do not jump into implementation plans unless the user asks to proceed.
- Do not produce a giant PM spec when a concise feature document will do.
- Do not skip critique; pressure-test the direction before presenting it as ready.

From tykowale/darwin, MIT.

More from tykowale/darwin