nebu-kaizen

name: "nebu-kaizen" description: "Default baseline skill for normal software work where the next logical step is clear: small safe iterations, built-in validation, and no unnecessary pauses between clear next steps. Use this for autopilot mode, keep going, ga door, werk door, or werk de stappen af zonder onnodige stopmomenten. Common triggers: kaizen, autopilot, keep going, continue without waiting, do not stop, don't stop, ga door, werk door, volgende logische stap, volgende stap, zonder te wachten, niet stoppen, gewoon doorgaan, ga verder, implement this, fix this, add this, pas dit aan, maak dit af."

Nebu Kaizen

Default to steady progress: inspect, create, test, review, continue.

If the next logical step is clear, keep going in autopilot mode instead of pausing for routine check-ins.

This also applies when the user phrases it in Dutch, such as ga door, werk door, ga verder, or zonder te wachten.

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. Keep going until the goal is done or a real blocker appears.

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.
5. Build only what the current requirement needs.
6. After code changes, do a proportional review pass. Load nebu-code-review when the diff is meaningful, subtle, or risky; tiny local diffs may stay self-reviewed.
7. When work reveals reusable workflow friction, capture the smallest durable improvement instead of treating it as one-off noise.
8. Reuse the repo's existing durable planning or spec system when one exists; do not create a parallel doc tree by default.
9. When editing code, follow the coding standards in AGENTS.md (## Coding standards). The intent-comment rule is a hard rule: every function, method, helper, closure handler, route handler, protocol dispatcher, and static utility gets a short comment above it. Add a brief docstring for non-obvious parameters, return values, side effects, or preconditions. Inline why comments stay focused on intent, not line-by-line narration.
10. For bounded mechanical chores, prefer a cheap-first subagent or mini path before reaching for a high-cost execution mode.

Use with

• nebu-kickoff for ambiguity that could change the implementation
• nebu-planning when sequencing or coordination needs a plan
• nebu-implementation for coupled edits and execution choices
• nebu-ui-ux for interface work that needs visual direction and screenshot-based review
• nebu-code-review after meaningful code edits and before handoff
• nebu-debugging for bugs, failing tests, and broken builds
• nebu-refactoring when the work is cleanup or simplification
• nebu-skill-improvement when repeated friction should become reusable skill or router fix
• nebu-verification before claiming success

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