using-darwin

Files (1)

• SKILL.md

SKILL.md (first lines)

# Using Darwin

This is an internal meta skill. Humans should not need to reference it directly.

## Purpose

Use Darwin's skill system before inventing a new workflow.

The goal is to keep the human interface small while routing actual work through deep meta skills, shared resources, and proven open source patterns.

## Core Rule

Before acting, check whether Darwin already has:

- a relevant meta skill
- a reusable prompt or template
- a proven pattern borrowed from open source

If one exists, use and adapt it instead of improvising from scratch.

## Priority

1. User instructions
2. Project instructions
3. Relevant Darwin meta skills
4. Shared resources
5. Default behavior

## Workflow

1. Identify the task.
2. Check whether a Darwin skill applies.
3. If no skill applies, check whether a shared resource or open source pattern should be reused.
4. If the task breaks into independent seams, delegate them to parallel agents and act as the orchestrator.
5. Keep direct implementation in the orchestrator only for tiny tasks or tightly coupled final integration.
6. Invoke the smallest effective set of internal skills.
7. Keep the human-facing response short and focused on results.

Deep internal context is a feature, not a failure mode. Prefer enriching Darwin's internal skills and resources over widening the human command surface.

For build tasks, route through the `build` skill, then use internal intent-clarification, plan-writing, execution-coordination, TDD, verification, and debrief workflows.

For modular work, prefer splitting along boundaries like:

- data contracts
- external API clients
- domain mapping
- state management
- UI integration

When those seams are independent enough, parallel agent work is the default, not the exception.

For early MVP or prototype work, prefer deterministic user-input seams over environment-dependent seams when that reduces ambiguity and makes dogfooding easier.

Examples:

- typed address before device geolocation
- manual search before background sync
- explicit refresh before automatic polling
- seeded fixture data before flaky live-device integration

## Guardrails

- Do not expand the human-facing skill surface unless necessary.
- Reuse and improve proven external patterns before creating new ones.
- Prefer composing existing skills over creating one-off logic.
- If a skill looks close but not perfect, adapt it rather than ignoring it.
- Do not hoard parallelizable work in the orchestrator when agents could investigate or implement it independently.
- Do not default to device capabilities, permissions, or simulator-dependent behavior when a simpler deterministic input would validate the product idea faster.

## Output

The user should experience a simple interface.

The complexity should stay inside Darwin.

From tykowale/darwin, MIT.

More from tykowale/darwin