Skip to content

Task-delivery pipeline

The pipeline turns a task description into a merged, deployed change while keeping a human in control at the points that matter. It runs entirely in the Claude Code terminal; each approval gate is an in-chat prompt.

Stages at a glance

/create-task   ->  AISD ticket created (Backlog)                [GATE: description]
/start-task    ->  branch + spec drafted, attached to Jira      [GATE: spec]
/approve-spec  ->  implement -> tests -> AI review -> PR to integration branch
                                                                 [3 in-terminal gates]
   (human approves the PR on GitHub)
/approve-pr    ->  verify human approval -> merge -> advance ticket
/release       ->  every 10 merged tasks: release branch -> PR to master

Ticket lifecycle (canonical status order)

AI Backlog
  < AI Spec Ready for Review
  < AI In Progress
  < Human PR Review
  < Stage QA
  < Ready for Release
  < Production Deploy
  < Monitoring
  < AI Done
  • Integration branch merge deploys automatically, so a merge to stage (or master in a stage-less repo) moves the ticket straight to Stage QA -- the Staging Deploy step is skipped.
  • Prod-side stages (Production Deploy, Monitoring, AI Done) are human/deploy-driven and are never set automatically from PR state.

Approval-gate discipline

Once the pipeline is running there are exactly two user-facing stops: after the ticket is created and after the spec is drafted. Everything else (implement, lint/test, commit, push, open PR, AI review) runs autonomously. Claude infers the target repo, title, and implementation details rather than asking.

The one hard human gate after that is the GitHub PR approval: the ticket waits in Human PR Review until a real person approves the PR. The AI code review is posted as an informational PR comment -- it never counts as the approval. /approve-pr is the only command that merges and advances the ticket, and it hard-blocks on that human approval.

Branching model

  • Per-task PRs target the repo's integration branch -- usually stage (variants exist, e.g. stage-py3 for skynet-dealer). Resolve it with hq/scripts/integration-branch.sh <repo>.
  • Stage-less repos (integration branch == default, e.g. hq): master is the integration branch, so per-task PRs correctly target master and a merge there means Stage QA.
  • Rollups reach master via a release/<version> branch cut from the integration branch -- never integration -> master directly.

Release rollups

A fixVersion accumulates merged tasks; at the threshold (10) it is ready_for_rollup. /release cuts the release branch, opens the PR to master, and links it on every task in the release. hq.release_check audits the merged count and PR merged: sentinels per version.

Supporting machinery

  • Model routing picks the cheapest capable model per phase (see rules).
  • Context cache pre-summarizes recurring context to save tokens (rules).
  • Deploy registry stores each repo's pipeline + host so deploys are checked without re-hunting AWS (rules).
  • Mock Jira (jira-mock/) mirrors real AISD tickets for local iteration.

See the Commands reference for the exact command at each stage.