robota

Pipeline for delegating one large mechanical change to a worker under a hard green-or-report gate — specify, dispatch mechanical-refactor-worker, independently re-verify the green claim, hand the working-tree diff to pr-review-reviewer, then commit. Route-only: it does no editing and forms no verdict. Use when delegating a big decision-free change on your own working tree.

Procedure for running multiple independent backlog items in parallel via worktree-isolated subagents with zero merge conflicts — partition file ownership before spawning, isolate each implementer in its own worktree, sequence overlapping work behind occupants, one coherent self-verified PR per agent, and serial orchestrator merge. Use when executing 2 or more independent items concurrently.

Thin router for the doc-vs-code architecture conformance audit (GATE-CONFORMANCE). Routes to the mechanical conformance scan plus the architecture-refresh agent loop (architecture-conformance-auditor / architecture-auditor + fixers), which own the audit behavior natively. Use before a release, after cross-package work, or when GATE-CONFORMANCE runs.

Router for the mandatory post-implementation sequence — SPEC sync, build/test, README, commit/PR, publish, content/ docs, docs deploy. Each step's detail lives in its owning skill/rule; this file only fixes the order and the gates. Execute automatically after implementation work; do not wait for the user to request it.

Orchestrator for the spec document gate pipeline. Reads current status from frontmatter, determines the next gate, invokes backlog-writer or backlog-gate-guard, and updates frontmatter status on PASS. Does nothing else.

Mandatory verification loop after any SPEC.md or contract document change. Compares spec against implementation code, fixes code to match spec, repeats until zero discrepancies, then runs regression tests. Spec is always the source of truth — never modify the spec within this workflow.

Use before implementing any change that adds, removes, or modifies package behavior, public API, types, or contracts. Ensures the governing spec is updated before code is written and a verification test plan exists.

Use when creating a new SPEC.md or incrementally updating an existing one. Covers both initial authoring and the ongoing incremental-update workflow that keeps the spec live.

Use immediately when the user requests any implementation, code change, feature addition, fix, or modification. Gates code writing behind a backlog draft document. Read-only exploration is always permitted.

Shared sub-orchestration for everything that happens AFTER a merge command returns — verify the merge actually landed, decide whether the source branch may be deleted and delete it, then reset the working tree onto a fresh integration base for the next branch. Routes on each step's outcome with a defined failure edge; it never forms the landing verdict itself. Dispatched by any pipeline that merges.

Orchestrator for the PR-review loop (HARNESS-018). Sequences the pr-review-reviewer (guardian) → pr-review-writer → pr-review-fixer agents on a PR, loops until the reviewer reports ACTIONABLE FINDINGS 0, bounded by a max-iteration cap + progress detection, then hands to the gated merge path. It manages ONLY the pipeline flow — it does not review, write, fix, or judge quality itself. Synchronous today (async firing is HARNESS-018a).

The state machine for executing ONE backlog item or named work unit end to end. Sequences five phases — recommendation gate, scenario planning, implementation, done gate, completion — dispatching proposal-reviewer and the user-execution-scenario sub-pipeline, and routing on each outcome (advance / repeat / return to an earlier phase / terminate). It holds NO backlog policy: every gate definition, PR contract, status invariant, and stop condition is owned by the project's backlog-execution rule and is pointed at, never restated. Use when working a backlog item; for an initiative spanning several items, multi-backlog-initiative is the entry point and dispatches this once per item.

Sub-orchestration for an initiative that spans several backlog items. Establishes an integration base branch cut from the integration branch, dispatches backlog-execution-orchestrator once per item against that base, keeps the base from drifting mid-flight, and opens the final PR that the user — never this pipeline — decides to merge. Owns only the ordering and routing between items; every branch, PR, and gate constraint is owned by the rules it points at. The entry point for multi-item work; a single item enters backlog-execution-orchestrator directly.

Sub-orchestration for the user-execution verification scenarios of one work unit. Runs in two modes at two moments — PLAN (before implementation: decide applicability, dispatch user-execution-scenario-author, gate that every scenario is written) and GATE (after implementation: execute each scenario, record the evidence, gate that it was executed and matched). Dispatches user-execution-scenario-author and backlog-gate-guard and routes on their outcomes. Holds no scenario criteria and forms no gate verdict. Dispatched by backlog-execution-orchestrator.

Shared sub-orchestration for waiting on a long-running gate (a CI run, a dry-run, a publish) without spinning. Loops observe → report the current job and step → decide, escalating a gate that exceeds the expected behaviour for its current step to ci-failure-triager for the stall verdict, and terminating any watcher it started. It observes and routes only; it never decides why a check is red. Dispatched by any pipeline step that waits on a gate.

Sub-orchestration for phase 3 of a release — the publish boundary. Sequences the strictly-ordered preflight (sync and already-published check, build, state-artifact readiness, publish preflight, registry auth, full dry-run), then the hard halt for the user's one-time password, then the single sanctioned publish command as the very next action, then post-publish verification. Every step must complete before the next; it routes on each outcome and never crosses the boundary early. Holds no publish policy. Dispatched by release-orchestration.

Top-level orchestrator for a release. Sequences three phases — source-stabilization → version-bump → npm-otp-publish — maintains the release control-plane state artifact across them, and routes on each phase's outcome (advance / repeat / return to an earlier phase / terminate). It holds NO release policy: every command name, gate definition, required field, and prohibition is owned by the project's publish rule and is pointed at, never restated. Use when running a release, a release-level merge, a version bump, or a publish.

Sub-orchestration for phase 1 of a release — getting the source branch green and landed on the release target. Sequences three steps (stabilize the source branch, open/refresh the source-to-target PR and wait for release-grade CI on the exact SHA, merge after green plus explicit approval), dispatching ci-gate-watch, ci-failure-triager, and merge-verifier, and routing on each outcome. Holds no gate definitions and no failure-classification criteria. Dispatched by release-orchestration.

Sub-orchestration for phase 2 of a release — cutting the bump branch from the freshly-fetched release target, applying the coordinated version bump, regenerating the changelog, running local release preparation, and landing the bump PR. Sequences six steps, dispatching version-management for the bump itself plus ci-gate-watch, ci-failure-triager, and merge-verifier, and routes on each outcome including the lockfile/diff-hygiene edge. Holds no versioning policy. Dispatched by release-orchestration.

Procedure for iterating on a PR's automated review feedback until it converges — fetch the findings (not the check status), judge each one, fix or refute it, push, then re-read the review the push re-triggered, and repeat until a fresh round yields nothing actionable. Use whenever a PR carries automated review output, before the merge is armed.

Invoke when the user says "turn this session's repeated requests into rules/skills", "교훈 처리해줘", "규칙으로 박아줘", or when the agent detects EITHER a repeated user correction/preference in-session (same kind of correction 2x+, or an explicit "from now on do/don't ...") OR a recurring agent/technical failure class (the same kind of failure hit 2x+ in-session — e.g. fixing the same category of CI failure twice — even with no user correction). Mines lesson candidates from the session, proposes them for approval, and institutionalizes only the approved ones as neutral, universal principles wired into the repo harness (.agents/rules, AGENTS.md, related skills, harness scan / hooks) as a single source — never memory-only. Fixing an instance never closes a recurring mistake; only a mechanical prevention does. Operationalizes learning-loop.md.

Defines the standard error response format for HTTP APIs based on RFC 7807 Problem Details. Use when implementing or reviewing API error responses.

Records architectural decisions with context, alternatives, and consequences using the ADR format. Use when making or reviewing significant design choices that affect multiple modules or packages.

Applies the repo's architecture patterns — functional core/imperative shell, ports-and-adapters, and DI-based composition. Use when designing module boundaries, separating domain from infrastructure, or improving testability.

Pointer — protected-branch commit/merge policy is owned by the git-branch.md rule and enforced mechanically by the branch-guard hook + husky pre-commit. Consult before committing when on main/master/develop.

Pointer stub — conformance findings reporting is owned by the architecture-conformance-auditor agent, which returns classified findings plus a machine-readable ACTIONABLE FINDINGS count natively. Dispatch it via the architecture-refresh pipeline instead of assembling a report from prose steps here.

Applies consumer-driven contract testing to verify API compatibility between packages or services without full E2E tests. Use when designing or evolving API boundaries between loosely coupled modules.

Pointer stub — the deep "is this design right?" audit (layer boundaries, coupling/cohesion, responsibility placement, type SSOT, extension seams, anti-patterns) is owned by the architecture-auditor agent, which judges by universal design principles natively. Dispatch it via the architecture-refresh pipeline instead of following prose steps here.

Pointer stub — per-document doc-vs-code claim verification is owned by the architecture-conformance-auditor agent, which emits HOLDS/DRIFT/VIOLATION/PHANTOM/UNDOCUMENTED verdicts with evidence natively. Dispatch it via the architecture-refresh pipeline instead of following prose steps here.

Models success and failure explicitly in TypeScript using Result or Either-like flows instead of uncontrolled exceptions. Use when implementing predictable error propagation across async workflows.

Turns classified conformance findings into a prioritized improvement proposal — maps each P0/P1 finding to a remediation, a proposed follow-up backlog ID + type prefix, and a mechanical-guard recommendation. Use as the remediation-planning step after an architecture-conformance-audit run.

Systematic per-package code review using six specialist perspectives (Correctness, Architecture, Type Safety, Security, Performance, Maintainability) with severity labels. Use when reviewing an entire package or a set of changed files for quality, compliance, and improvement opportunities.

pnpm workspace build gotchas — lifecycle-script (pre/post) silence and surgical lockfile edits for workspace dependencies. Use when a build step silently does not run or when adding/removing a workspace dependency.

Before modularizing or refactoring a package, analyze the code for extraction points, write characterization tests for current behavior, then modularize under test protection. Use when a package has monolithic files that need to be broken into testable modules.

Use when reviewing a package's class contract relationships (interface implementations, inheritance chains, cross-package port consumers) and updating its SPEC.md Class Contract Registry.

Verify a change against a recorded scenario — check scope, preserve canonical ownership of the recorded artifact, re-record only on intentional behavior change, and stop on verification failures. Use when scenario files, example flows, or execution-path behavior changes.

All packages must have the same version. Use changesets for coordinated version bumps. Never version packages independently. Includes the semver impact classification for public API surface changes.

Guides authoring of a new spec document. Ensures every required section is present and meets minimum quality before the item enters the gate pipeline. Does not validate gates or make approval decisions.

Generate the committed daily work report (OBSERVABILITY-001) — one markdown summary per UTC day that had work. Use when a UTC hour boundary passes during active work, or to catch up missing reports.

Governs the Robota harness by checking rule-skill-owner consistency, finding undefined terminology, spotting examples that violate rules, and preferring mechanical checks over duplicated prose. Use when editing AGENTS, skills, or repository guidance.