Delivery Harness Framework / Skill Inventory

Every DHF step, every owning skill.

This page maps the current Delivery Harness Framework workflow to the skills used at each step, explains what each skill does, and links directly to the GitHub source for that skill.

How to read this

DHF starts with routing, then delegates.

The lifecycle router recovers durable state, classifies the stage and execution lane, and chooses a specialist workflow. Helper scripts validate requirements, agent plans, evidence, and checkpoints; this matrix focuses on skills because they define the agent behavior at each step.

Step 01

Recover and route

Start or resume complex work from durable repo state before choosing the next workflow.

delivery-harness-framework

Reads repo guidance, recovers current phase, classifies the lifecycle stage, selects the next skill/helper route, and defines evidence gates.

GitHub source
shipq-lifecycle-harness

Example repo-specific lifecycle adapter. Takes over when a known repository needs domain paths, local commands, fixtures, or deployment boundaries.

GitHub source
Step 02

Requirements

Turn ambiguity into success criteria, scope, constraints, and source-of-truth artifacts.

planner

Analyzes complex requirements, architecture context, task decomposition, and implementation risks before code changes.

GitHub source
req-to-dev

Converts requirements or principles into an executable development package with plans, safety net, contracts, acceptance tests, and owner handoffs.

GitHub source
vendored gstack spec

Turns fuzzy implementation intent into a backlog-ready issue, ticket, or executable spec while preserving DHF source-of-truth, lane, and verification boundaries.

GitHub source
Step 03

Planning

Lock product, engineering, design, and execution decisions before scoped implementation.

delivery-harness-framework

Owns the architecture alignment checkpoint when durable sources conflict: compare product, process, components, data ownership, lane, security, slices, and handoff state before edits.

GitHub source
gstack-plan-eng-review

Reviews architecture, data flow, edge cases, test coverage, performance, and operational risks; can use structured planning context when gbrain is configured.

GitHub source
gstack-plan-ceo-review

Pressure-tests product framing, scope, user value, strategy, and whether the plan should expand, hold, or reduce scope.

GitHub source
gstack-office-hours

Runs founder-style or builder-style office hours to expose demand reality, narrow the wedge, and clarify the product idea; can use gbrain preflight when configured.

GitHub source
gstack-plan-design-review

Reviews UX structure, visual direction, responsive behavior, and design acceptance criteria; gbrain context is specialist planning input, not a substitute for repo state.

GitHub source
task-flow-orchestrator

Orders the execution workflow across Karpathy-style thinking, planning, TDD, and verification for complex work.

GitHub source
planner / prototype route

Use throwaway prototypes only to answer one named data model, state machine, module interface, or UI question, then delete the prototype or capture the durable decision.

GitHub source
Step 04

Development

Implement scoped changes with tests appropriate to behavioral and user-facing risk.

tdd-guide

Enforces a RED -> GREEN -> REFACTOR loop for feature work, bug fixes, refactors, and core business logic.

GitHub source
atdd-guide

Starts from business-facing acceptance scenarios, then drives implementation through executable specifications and production-like checks.

GitHub source
gstack-investigate

For bugs, wrong output, broken UI flows, or unclear root cause, establish a runnable feedback loop before patching from inspection.

GitHub source
Step 05

Validation

Prove the implemented or documented change with fresh command evidence.

verification-loop

Runs the delivery verification pass across build, static checks, tests, coverage, and security scan where applicable.

GitHub source
delivery-harness-framework

Requires completion evidence with command, exit code, key output, timestamp, demand-matched gate selection, effective feedback check, and conversion health status when local evidence exists.

GitHub source
Step 06

Review and QA

Find regressions, user-visible failures, security risks, and missing tests before release.

gstack-review

Performs pre-landing diff review for structural risks, trust boundaries, conditional side effects, and merge readiness.

GitHub source
code-reviewer

Reviews staged, unstaged, or PR changes for correctness, security, maintainability, and project standards.

GitHub source
review-swarm

Runs parallel read-only review agents across behavioral, security, performance, reliability, and test coverage risks.

GitHub source
gstack-cso

Runs infrastructure-first security and privacy review for auth, tokens, secrets, PII, approvals, audit trails, and public/private boundaries.

GitHub source
security-reviewer

Checks input validation, authentication, authorization, secret leakage, injection, and error disclosure risks.

GitHub source
gstack-qa

Runs systematic browser QA, screenshots, console/network checks, responsive checks, and iterative bug verification.

GitHub source
gstack-qa-only

Runs report-only browser QA when the user wants findings, screenshots, and risk notes without automatic fixes.

GitHub source
committee-review-loop

Only explicit committee, expert panel, reviewer/worker, rating loop, or target-score requests route here; ordinary reviews keep their specialist route.

GitHub source
Step 07

Committee rating loop

Use only when the user explicitly asks for committee/subagent review and a target score.

committee-review-loop

Creates a three-domain expert committee, collects ratings and findings, gives a revision brief to a worker, and repeats until the target rating or a blocker is reached.

GitHub source
Step 08

Ship and deploy

Move verified work through commit, PR, merge, deployment, and production monitoring when explicitly requested.

gstack-ship

Runs the opinionated ship workflow: detect base branch, test, review diff, update release metadata, commit, push, and prepare PR.

GitHub source
gstack-land-and-deploy

Merges and deploys after ship, waits for CI/deploy completion, and verifies production health.

GitHub source
gstack-canary

Performs post-deploy canary monitoring for console errors, performance regressions, page failures, and screenshot drift.

GitHub source
Step 09

Handoff and learning

Preserve recoverable state and capture durable learning when work spans sessions.

gstack-retro

Creates engineering retrospectives from commit history, work patterns, quality metrics, and team-aware summaries.

GitHub source
gstack-learn

Reviews, searches, prunes, and exports project learnings so future sessions reuse operational knowledge.

GitHub source
gstack-plan-tune

Tunes repeated planning questions, developer profile signals, and question preferences; this is operator preference state, not repo lifecycle state.

GitHub source
Step 10

Documentation release

Keep public docs, README, routing specs, and release notes aligned with shipped behavior.

gstack-document-release

Performs post-ship documentation updates across README, architecture docs, changelog voice, TODOs, and version notes.

GitHub source
doc-updater

Updates docs, codemaps, README, guides, paths, and examples after feature, API, or architecture changes.

GitHub source
skill-evaluator

Evaluates whether a skill should exist, how it should route, what evals it needs, and whether it improves behavior over baseline.

GitHub source
visual-explainer

Builds self-contained HTML diagrams, flowcharts, architecture views, and visual explanations for complex technical concepts.

GitHub source