lean-md

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation. Use when starting creative work that will produce a versioned design spec.

Use when you need to render an lmd-* skill phase or companion, or when a render call fails and you must decide whether the gateway is broken or the call was misaddressed.

Use when implementing any feature or bugfix, before writing implementation code

Use when creating new skills, editing existing skills, or verifying skills work before deployment

Fans out one focused subagent per independent problem domain (disjoint files, no shared state), then conflict-scans and integrates. Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies.

Executes a .lmd.md plan in this session — the main agent runs each task itself, pauses at batch checkpoints for human review, and closes at a whole-branch final gate. No companions. Use when executing an implementation plan inline with human review checkpoints.

Guides branch completion by verifying tests, detecting the workspace environment, presenting exactly 4 (or 3 for detached HEAD) integration options, then executing the choice with provenance-based worktree cleanup. Use when implementation is complete and you must decide how to integrate the work — merge, PR, keep, or discard.

Executes a .lmd.md plan one task at a time — a fresh implementer subagent per task, two-verdict review between tasks, a whole-branch final review — all handoffs over lean-ctx memory/coordination. Use when executing an implementation plan with independent tasks in the current session.

Produces token-efficient `.lmd.md` implementation plans (task-on-demand render, code anchors, @define/@call macros) without functional loss. Use when you have a spec or requirements for a multi-step task, before touching code.