---
name: develop
description: "Default baseline skill for normal software work: small safe iterations, built-in validation, no unnecessary pauses between clear next steps. Includes mode selection (direct, batch, delegate) and cheap-first escalation for bounded mechanical chores."
default: true
execution_tier: standard
delegation_default: auto
triggers:
  - develop
  - kaizen
  - autopilot
  - keep going
  - continue without waiting
  - do not stop
  - don't stop
  - ga door
  - werk door
  - volgende logische stap
  - volgende stap
  - start working
  - start coding
  - get started
  - zonder te wachten
  - niet stoppen
  - gewoon doorgaan
  - ga verder
  - implement this
  - fix this
  - add this
  - pas dit aan
  - maak dit af
  - implement
  - implementeer dit
  - keep coding
  - continue implementation
  - work through steps
  - code change
  - start implementing
  - start implementation
  - batch edits
  - delegate work
  - subagent
  - maak dit werkend
---

# Nebu Kaizen

Default to steady progress: inspect, create, test, review, continue. If the next logical step is clear, keep going without pausing for routine check-ins.

## Choose the mode

- **Direct:** known files, tight coupling, fast iteration, nuanced judgment
- **Delegate:** independent research, parallelizable subtasks, noisy command runs, or specialized review
- **Batch:** related reads, searches, and edits that can be done safely together

## Cheap-first escalation

1. Start bounded mechanical chores on the smallest viable agent or subagent.
2. Validate the result before widening context.
3. Escalate to default agent only if scope grows beyond the original bounded task.
4. Escalate to high or xhigh only for cross-cutting, analysis-heavy, or repeatedly failing work.

## Core loop

1. Inspect the next boundary that matters.
2. Create the smallest coherent improvement.
3. Test it with the fastest trustworthy proof.
4. Review it for clarity, safety, consistency, and scope.
5. Continue unless a real blocker or decision point appears.

## Git workflow (default)

### Feature
1. Branch van main: `git checkout -b feat/description main`
2. Open draft PR meteen met titel + korte scope beschrijving
3. Commit iteratief, push regelmatig, PR updatet vanzelf
4. Klaar? Mark PR ready → review → squash merge met Conventional Commits message
5. Delete remote + local branch, `git checkout main && git pull`

### Bugfix
Zelfde flow, `git checkout -b fix/description main`. Draft PR optioneel (klein genoeg om direct te openen).

### Hotfix
Zelfde flow als release: fix branch → PR → merge → tag. Geen feature iteratie.

## Default rules

1. Do not stop after every milestone when the next step is already clear.
2. Ask only when the answer changes scope, product behavior, architecture, safety, or acceptance.
3. Prefer preventing mistakes early with types, validation, guards, and simpler control flow.
4. Follow existing repo patterns before inventing new ones. Build only what the current requirement needs.
5. After code changes, do a proportional review pass. Load `code-review` when the diff is meaningful, subtle, or risky.
6. When work reveals reusable workflow friction, capture it with `write-skill`.
7. Reuse the repo's existing durable planning or spec system; do not create a parallel doc tree.
8. Delegate only when the work is parallel, repetitive, or context-heavy.
9. Volg de standaard git workflow: branch, draft PR, commits, squash merge, cleanup.

## Use with

- `intake` for ambiguity that could change the implementation
- `ui-ux` for interface work that needs visual direction and screenshot-based review
- `code-review` after meaningful code edits and before handoff
- `debugging` for bugs, failing tests, and broken builds
- `verification` before claiming success
- `refactor` when the codebase needs a structured audit or refactoring pass

## Avoid

- Big-bang rewrites when an incremental change will do
- Speculative abstractions or future-proofing theater
- Repeated approval pauses during obvious execution
- Leaving small in-scope paper cuts behind when they are cheap to fix safely
- Re-reading the same files without learning anything new
- Delegating tightly coupled changes that need shared judgment
- Treating process as a substitute for thinking