hitl

Review HLD, LLD, and ADR for a feature — verify design is implementable and manifest-consistent before approving implementation

Integration verification — confirm the issue → design → code → tests chain is intact, E2E + smoke suite pass, and the impact brief is complete before merge

Code review — compare implementation against the approved LLD and system manifest for spec adherence, edge case coverage, and convention compliance

Canary monitoring — read observability dashboards for an active canary deployment and produce a go/no-go recommendation for the next promotion step

Ops review — assess rollout plan, canary criteria, observability readiness, and rollback procedure before release

Architecture reviewer agent. Reviews HLDs, LLDs, and ADRs for technical correctness, domain boundary compliance, and manifest consistency. Use when a design needs independent review before implementation is approved. Write access limited to docs/02-design/.

Developer implementation agent. Generates code, tests, and IaC from approved LLDs and HITL context. Only operates when a valid .hitl/current-change.yaml and approved LLD exist. Write access covers src/, tests/, docs/02-design/technical/lld/, and IaC files within the approved manifest domain.

Ops release reviewer agent. Reviews rollout plans, canary criteria, observability readiness, and rollback procedures for Tier 2+ releases. Use before merge on any change with medium or higher deployment risk. Write access limited to deployment docs and IaC review (no source code edits).

Product Manager reviewer agent. Reviews PRDs, acceptance criteria, and feature requirements for completeness and clarity. Use when evaluating whether product requirements are sufficient to proceed to design. Write access limited to docs/01-product/ and GitHub issues.

QA reviewer agent. Reviews test plans and test evidence against acceptance criteria and the incident registry. Use after the TDD cycle is complete to verify test coverage is sufficient before architect code review (step 19a). Write access limited to tests/ and docs/ (test registry updates only).

Orchestrate the architect's design journey for a change — steps 3 through 9. Covers impact analysis, HLD and LLD generation with approval gates, slice decomposition, test case planning, and decision packet assembly. Produces decision packets ready to hand to developers. Do not invoke spontaneously; requires a GitHub issue.

Design a new system from scratch starting from a PRD. Produces domain decomposition, system manifest, HLDs, ADRs, LLDs, and an initial delivery plan — demoable slices sequenced by dependency, each with a decision packet ready to hand to a developer. Run once at project inception.

Human architect code review — step 19a. After AI rounds 1 and 2 have resolved mechanical issues (LLD conformance, conventions, test coverage), the architect reviews for judgment calls that AI cannot assess: business logic correctness, architectural consistency, domain boundary integrity, hidden coupling, and naming clarity. Blocks progression to step 20 until the architect explicitly approves.

Architect review of an existing codebase. Reads the system manifest and code to reconstruct what architectural decisions were already made, interviews the architect to confirm rationale and constraints, then documents them as real ADRs. Run during brownfield onboarding after the system manifest is generated and before incremental feature work begins.

Apply the HITL dev-practices workflow to analyze and plan a change before writing any code. Use when a developer is about to start implementing a feature, bug fix, or refactor and needs to produce an impact analysis, documentation plan, test plan, and execution order. Refuses to proceed if no GitHub issue exists.