RubenGlez

dev-plan

Analyze product docs from an engineering perspective to decide architecture, tech stack, tools, and implementation approach — then generate a technical spec for every feature in the roadmap. Reads .harness/product/ first, interviews the user, then writes docs via parallel subagents. Use after product-plan. The output feeds directly into implement.

handoff

Compact the current conversation into a handoff document for the next agent or session. Saves to the OS temp directory — never to the repo. Includes current state, artifacts written, decisions made, and the suggested next skill. Use at the end of any phase to prepare a clean starting point for the next session.

Code & Development Listed

ideate

Research a product idea on the web to assess market viability, identify competitors, and decide whether to pursue it. Searches for existing solutions, GitHub repos, ProductHunt listings, and community signals. Writes .harness/product/idea.md. Use as the very first step when you have a new project idea, before product-plan.

implement

Read the engineering docs, classify each feature as HITL (needs human approval) or AFK (autonomous), then implement the next phase as vertical slices using parallel subagents. Each subagent implements one feature end-to-end through all layers. Updates feature status in .harness/engineering/features/. Use after dev-plan (and optionally prototype) has produced feature specs.

product-plan

Define the full product vision — audience, positioning, features, roadmap, and UX direction — through a structured interview. Reads .harness/product/idea.md (from ideate) as a starting point to skip already-answered questions. Writes structured docs to .harness/product/. Use after ideate, or directly when the idea is already validated.

prototype

Build throwaway code to answer a specific design question before full implementation. Use when a feature in the roadmap has high technical uncertainty — you don't know if an approach will work, which library fits, or what the state machine looks like. Produces a runnable spike, captures findings in the feature spec or an ADR, then deletes the prototype code. Use between dev-plan and implement.

Testing & QA Listed

qa

Test implemented features against their acceptance criteria using available tools (Playwright for web apps, shell for CLI/API, test runner for libraries). Builds a fast feedback loop first, fixes simple failures, and documents results plus any architectural gaps in .harness/qa/report.md. Use after implement has finished a phase.

update-docs

Update all project documentation to reflect the current state of the codebase. Refreshes .harness/product/, .harness/engineering/, .harness/adr/, and public root docs (README.md, DESIGN.md, CHANGELOG.md). Use after finishing a feature, refactor, or any meaningful change — or whenever docs feel stale.

Data & Documents Listed

migrate-docs

Discover all existing documentation in the repo — public and private, wherever it lives — classify each file, transform the content to match harness templates, and migrate everything to the correct location (.harness/ for internal docs, repo root for public docs). Use on any existing project to adopt the harness workflow without starting from scratch. Safe: never deletes originals without explicit confirmation.

zoom-out

Go up a layer of abstraction and map all relevant modules and their callers. Use when you're lost in a section of code and need to understand how it fits into the bigger picture, or before making a change that could have unexpected reach.

next-step

Recommends the next harness skill to use by inspecting the repo, docs, git state, and recent work. Use when asking what to do next, which skill comes next, or when the workflow phase is unclear.