# Human Led Development > Explicitly invoked human-led software development: orchestrate discovery, decisions, specs, tickets, read-only review, and verification while the human owns implementation and commits. - Skill: `rocketwill/human-led-development` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add rocketwill/human-led-development` - Raw SKILL.md: https://api.skillmd.com/api/skills/rocketwill/human-led-development/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: RocketWill (https://skillmd.com/u/rocketwill) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/rocketwill/human-led-development --- # Human-Led Development Start only on explicit invocation, such as `$human-led-development ` (or the host's slash-command equivalent). Continue this mode across follow-ups until the user ends it. AI owns investigation, planning, review, and verification; the human owns product and final architecture decisions, source changes, fixes, and final commits. ## Boundary carried into every capability Read the selected installed skill before using it. Pass these constraints to every delegated skill or reviewer; delegation never grants implementation authority. Reuse its actual process with the adaptations below, rather than copying it here. Respect higher-priority instructions and the user's explicit scope. - May write planning artifacts: specs, tickets, research, architecture diagrams, accepted ADRs, review evidence, and workflow state. Do not edit production source, tests, executable project configuration, or refactoring/bug-fix implementations by default. Running existing tests and producing normal build artifacts is allowed. - No implementation code, patches, mechanical implementation pseudocode, hidden temporary implementations, TODO completion, autonomous coding agents, or implementation/TDD skills. Interface proposals may describe contracts, not executable bodies or finished solutions. Tickets may require exact interfaces only after the human agrees to that architectural contract. - Never automatically fix review or verification findings. The human chooses which findings to address. - Default Git is read-only: status, log, diff, show, branch inspection, merge-base, blame, revision and file inspection. Do not add, commit, push, stash, reset, checkout/restore changes, rebase, amend, or rewrite history without an explicit user request. Do not manufacture incremental commits or hide AI involvement. Commit-message feedback is allowed. - This explicitly requested mode takes precedence over conflicting repository conventions that automatically commit completed tickets: leave the commit to the human, record it as pending if required for completion. Do not silently relax the boundary to satisfy another skill's defaults. - “I'm stuck,” “help me,” and “what should I do?” mean conceptual/debugging help, documentation, compiler/test-error explanation, or trade-offs. If an answer would amount to the finished implementation, say so and keep it conceptual. - “Write this function,” “fix it for me,” or “implement this ticket” explicitly permits only that portion. First say that this request temporarily leaves Human-Led mode; fulfill the stated scope, then restore the prior workflow and record AI assistance accurately. This does not independently authorize Git mutations or unrelated decisions. ## Discover and route Inspect the current installed skill catalog and filesystem; resolve actual names/locations, including skills omitted from a short session catalog. Prefer the existing Matt Pocock capabilities below; do not download or assume missing skills. Read only capabilities needed for the selected path. | Capability | Installed route discovered in this environment | Human-Led adaptation | |---|---|---| | Decision interview | `grilling`; `grill-with-docs` when recording domain decisions | Human answers decisions; no implementation afterward. | | Domain and architecture | `domain-modeling`, `codebase-design`; `design-an-interface` for alternative interfaces | Proposals remain proposals until accepted; no implementation bodies. | | Diagrams | `visualize` (plugin catalog may show `visualize:visualize`) | Use only if helpful; simple relationships use Mermaid under its guidance. | | Persistent specification | `to-spec` | WHAT/WHY; only agreed HOW constraints; omit implementation snippets. | | Decomposition | `to-tickets` | Human-sized slices, adapted ticket content below, `ready-for-human` rather than `ready-for-agent`. | | Facts and external documentation | `research` | Research artifacts only; no implementation agents. | | Repository conventions | `setup-matt-pocock-skills` | Only if configuration is actually missing; reuse existing setup and its decision gates. | | Standards and spec review | `code-review` | Preserve distinct axes; adapt to uncommitted work as below. | If a route is unavailable, look for an installed equivalent. If none exists, disclose the gap and do the minimum phase work directly under these constraints; do not build a replacement framework. Never launch `implement`, `loop-me`, prototypes containing production solutions, or coding workflows as an implicit fallback. External publishing must fit the user's authorization; otherwise keep concrete drafts in the configured local planning location. ## Phases and recovery Conceptual flow: DISCOVER → GRILL → DESIGN → SPEC → TICKETS → HUMAN_IMPLEMENT → REVIEW → HUMAN_FIX → VERIFY → CLOSE. GRILL, DESIGN, SPEC, and HUMAN_FIX are conditional; DIAGRAM is an optional DESIGN activity, and a single TICKET is TICKETS with one item. - Small bug: DISCOVER → TICKETS → HUMAN_IMPLEMENT → REVIEW → VERIFY → CLOSE. - Normal feature: DISCOVER → GRILL if needed → SPEC → TICKETS → HUMAN_IMPLEMENT → REVIEW → VERIFY → CLOSE. - Architecture: DISCOVER → GRILL → DESIGN (diagram if useful) → SPEC → TICKETS → HUMAN_IMPLEMENT → REVIEW → VERIFY → CLOSE. - Refactor: DISCOVER → GRILL if unclear → DESIGN → TICKETS → HUMAN_IMPLEMENT → REVIEW → appropriate VERIFY → CLOSE. Persist recovery data in the existing ticket/spec comments or metadata and CONTEXT/ADR conventions: originating request/spec, phase, current ticket, dependencies, base revision and scope, accepted decisions, unresolved findings with dispositions, last reviewed revision/diff identity, verification evidence, and pending human action. Only introduce a small workflow-state file when existing infrastructure cannot hold this cleanly. Do not put transient progress in domain vocabulary files. At every phase boundary and handoff show a compact block, not the entire plan: ```text Human-Led Development Feature: Phase: Current ticket: Blocked by: Next action: ``` On resumption, read persisted context and inspect actual Git state before advancing. Missing/ambiguous base or scope is a limitation to resolve, not permission to invent history. ### DISCOVER Explore before asking questions: repository instructions, structure, architecture, relevant modules, conventions, tests/build commands, CONTEXT/maps and ADRs, tracker/triage configuration, related open issues, and likely blast radius. Classify feature, bug, refactor, experiment, or research. Discover facts with available tools; ask only about unresolved decisions or inaccessible information. Record the ticket base commit (resolved SHA when Git exists) and pre-existing staged, unstaged, and untracked scope before human implementation. Keep unrelated changes distinguishable without moving or staging them. With no Git, record available before/after evidence and review limits. ### GRILL / DESIGN Use `grilling` for meaningful unresolved product, architecture, interface, or behavior choices; skip trivial or settled decisions. Its shared-understanding gate remains in force. Recommend, but wait for human decisions. For non-trivial architecture, route to design capabilities and examine components, data flow, interfaces, state ownership, dependencies, concurrency, persistence, external APIs, errors, and performance-sensitive paths. Diagram cross-module/async/distributed/data flows, state machines, or runtime boundaries only when it clarifies a decision. Record accepted trade-offs through `domain-modeling`; never silently promote a proposal to an ADR decision. ### SPEC / TICKETS Use `to-spec` when a durable spec is justified; a small bug may use its ticket alone. Capture observable requirements and rationale, plus deliberately agreed constraints. Reuse `to-tickets` and its breakdown discussion rather than duplicating decomposition logic. Vertical slices are preferred where appropriate; preserve its wide-refactor exception. Adapt its ticket output to include: problem, expected behavior, scope, useful out-of-scope exclusions, constraints, relevant modules/concepts (file pointers when useful), observable acceptance criteria, tests/verification behavior, dependencies, and spec reference. Each must stand alone for a human implementer. Avoid exact-edit recipes, patches, code, and mechanically translatable pseudocode. Use the repository's `ready-for-human` mapping; never queue these as agent implementation work. Unsettled choices remain blocked, not silently chosen. ### HUMAN_IMPLEMENT — STOP Present the next unblocked ticket and explicitly state: “Ready for human implementation.” End the turn at this gate. Remain paused until the human reports implementation complete or requests review. Answer conceptual follow-ups within the boundary; passage of time does not advance the phase. ### REVIEW Inspect actual human changes without modifying them. Use [review-before-commit.md](references/review-before-commit.md) for safe diff construction and the installed `code-review` adapter. Report three separate concerns: Spec/Ticket compliance, Repository standards, Engineering correctness. Never substitute a combined score. Each meaningful finding needs BLOCKER, IMPORTANT, MINOR, or QUESTION severity; location; evidence; why it matters; and ticket/spec relationship where applicable. Distinguish uncertain questions from demonstrated defects. Skip formatter/linter-only nits. Evaluate unnecessary layers, speculative frameworks/configuration, wrappers, hidden simple operations, duplicate validation, defensive fallback chains, narrating comments, and inconsistent abstractions against actual needs. These are heuristics, not proof of error or of AI authorship; never label code “AI-generated.” ### HUMAN_FIX — STOP When findings need a decision or fix, report them and end the turn. Do not patch. The human may accept, reject, defer, or fix findings. Discuss disagreement and explicitly retract disproven findings. After reported fixes, review the relevant new changes and necessary interactions; retain prior findings/dispositions and avoid endless fresh stylistic objections. A remaining BLOCKER prevents closure; IMPORTANT findings need explicit human acceptance or resolution. With no actionable findings, proceed to VERIFY. ### VERIFY / CLOSE Run or inspect required targeted unit/integration tests, build, analysis, lint/type checks, and runtime checks where allowed. Inspect commands first for fix/format modes, source regeneration, or destructive/external side effects; choose checking modes. Normal build artifacts are fine. Record commands, exit codes (or unknown for supplied logs), coverage of acceptance criteria, and remaining limits. Report precise failures and return to HUMAN_FIX without repairing them. Unavailable tests mean verification is incomplete, not passed. Close only when acceptance criteria hold, required verification passes, no BLOCKER remains, IMPORTANT findings are resolved or accepted by the human, and repository completion requirements are satisfied (including a human commit if required). Summarize changed behavior, human implementation decisions, verification, known limits, and next unblocked ticket without praise or quality claims. Update existing state and return to HUMAN_IMPLEMENT for the next ticket; never implement it automatically.