build

Files (1)

• SKILL.md

SKILL.md (first lines)

# Build

This is a human-facing skill.

Use it when the user wants Darwin to build, implement, or change something.

## Purpose

Turn a build request into a tight loop:

1. clarify
2. design
3. plan
4. get approval
5. execute through coordinated delegation and TDD
6. debrief and learn

## Dependencies

- `using-darwin`
- `clarifying-intent`
- `writing-plans`
- `execution-coordination`
- `frontend-work`
- `test-driven-development`
- `verification-before-completion`
- `debrief-and-learn`

## Role

`build` is the narrow human-facing orchestrator.

Its job is to:

- decide when clarification is needed
- route to the right internal skills
- present an approvable checklist
- hold the approval gate
- keep progress visible
- ensure verification and debrief happen before cleanup

## Clarification Rule

Ask at most 3 clarifying questions before presenting a plan.

Questions should only be used to remove meaningful uncertainty about:

- scope
- constraints
- success criteria

If enough is already clear, ask fewer than 3 questions.

## Planning Rule

After clarification, use `clarifying-intent` internally to resolve purpose and success criteria when needed, then use `writing-plans` internally to turn the approved direction into a concise checklist that can survive compaction.

For early MVP work, the plan should prefer the smallest deterministic flow that can validate the product idea before reaching for environment-dependent behavior like device permissions, geolocation, or background execution.

Use this format:

```md
## Plan
- [ ] Step 1
- [ ] Step 2
- [ ] Step 3
```

## Approval Rule

Do not start implementation until the user accepts the plan.

If the user rejects the plan or asks for a different direction, reset the clarification budget and allow up to 3 new questions for the revised plan.

## Execution Rule

After plan approval, route execution through the appropriate internal skills:

- `execution-coordination` for delegation, sequencing, review, and integration
- `frontend-work` for frontend and UX-heavy work
- `test-driven-development` for behavior-changing implementation
- `verification-before-completion` before claims, commits, or cleanup
- `debrief-and-learn` before final cleanup

## Output To The User

Keep the human interaction simple:

- a small number of high-value questions
- a clear checklist to approve or reject
- concise progress updates during execution
- a short debrief summary with both Darwin learning and operator feedback

From tykowale/darwin, MIT.

More from tykowale/darwin