lifeline

Drive the full lifeline lifecycle (spec → plan → build → review → test → merge, plus a debug lane) with approval gates, structured payloads, coverage-honest testing, and reviewer/QA handoff docs. Portable - speaks only @primitives bound by the active harness adapter.

Lifeline architect role. Produces approaches with architectures (stage 1) and dependency-ordered wave breakdowns with effort labels (stage 2) via the planning-waves skill.

Lifeline implementer role. Executes one planned task with TDD discipline via the implementing-task skill. Returns TASK_UPDATE.

Lifeline investigator role (debug lane). Read-only root-cause analysis per systematic-debugging phase 2. Returns RCA_RESULT.

Lifeline reproducer role (debug lane). Captures a reported bug as a deterministic failing test per systematic-debugging phase 1. Returns REPRO_RESULT.

Lifeline reviewer role. ONE review per task, always all four lenses (logic, architecture, security, performance), depth scaled to task effort, via the four-lens-review skill. Returns REVIEW_FINDINGS JSON.

Use to statically check a lifeline harness adapter — "is my adapter healthy", "lifeline doctor", "are all primitives bound", before relying on a fresh or edited adapter. Read-only diagnostic; reports binding + file-wiring status without running a cycle.

Use when tests pass and you're about to merge, when asked "are we sure this works", "did we test everything", "is this covered", or before opening a PR. Turns per-changed-file coverage gaps into a human smoke checklist so untested paths get exercised before merge. Pure methodology — no harness capabilities required.

Use at lifeline setup, or when asked "what lint/test commands will lifeline run", "detect my project tooling", "configure lint for this repo". Inspects the repo's OWN config to propose the user's lint/test/coverage commands instead of imposing built-in tool choices.

Use when reviewing code - "review this", after implementation, before merge. ONE review per task, ALWAYS all four lenses (logic, architecture, security, performance), with depth scaled to the task's effort label. Returns structured REVIEW_FINDINGS.

Use when opening a PR, publishing, handing work to a human reviewer or QA team, or when a cycle reaches merge. Generates two structured handoff documents from cycle artifacts - a REVIEWER_DOC (code-visible, detailed change explanation) and a QA_DOC (blackbox flow + test cases). Pure methodology - no harness capabilities required.

3 hooks across 3 events