/using-the-harness

name: using-the-harness
description: Session-start orientation for this team harness. Load first, before any work. Explains the operating contract, when each skill triggers, and how installed companion plugins supply agent-craft capabilities while this harness supplies the team contract. Trigger at the start of every session and whenever unsure which skill applies.

Using the Harness

This is a **team operating harness**: one shared contract for humans and AI agents working in the same repository — same rules, same risk tiers, same evidence, same definition of done. It exists to make a mixed human–AI team coherent, not to make one agent faster.

A skill supplies a repeatable procedure. It never supplies permission or accountability.

First actions, every session

1. **Ground in the contract.** If this project has adopted the operating model, read its project profile before anything else (`docs/operating-model/PROJECT-OPERATING-PROFILE.md`), then the manual it binds. Load the mapped delivery workflow, current STATUS, ROADMAP and any applicable checkpoint before planning. Check dates and executable commands against current evidence; a stale profile is a finding, not a fact to silently preserve. Hooks provide orientation, not proof that these reads happened. 2. **Classify risk before acting.** Map the requested work to R0–R3. Round ambiguity upward. Confirm authority at that tier before any consequential, destructive, external, or credential-touching action. 3. **Route before doing.** Check the routing table below. If a skill applies to the work, use it. If you are unsure which applies, use `delivery-orchestrator`.

The shared plugin is provider-neutral. Host adapters implement invocation; the project profile selects authorised reviewers, subscriptions and budgets. Independent Council review is a capability, not a fixed roster. See the [review contract](../pr-reviewer/references/independent-council.md).

Installation and project adoption

A user-level installation makes the skills available across that user’s projects; a project installation shares a selected baseline with collaborators. Neither creates project authority. Use the host’s selected skill location, including bundled references and scripts, without assuming a copied `.agents/skills/` directory.

For a new adoption, route to `operating-model-bootstrap` from the consumer project. Ground its project-owned vision, workflow and profile: ticket system, owners, model selection, executable checks, review, release and observation. Existing records and explicit operator authority take precedence. Load detailed skills when needed; an unadopted project needs orientation and an adoption path, not the full delivery process.

Core invariants — not negotiable

• **Classify risk before confirming authority.** Approval is scoped to actual risk.
• **Infer intent; never infer permission.** Useful intent is not a grant of authority.
• **Receipts, not polish.** Produce an artefact or a pass/fail verdict, not a narrative.
• **Review binds to the exact candidate.** Any change after review invalidates it.
• **`seed` is not `active`.** A seed profile supports design and R0/R1 work only.
• **Never invent a project fact.** Unknowns get an owner and a resolving trigger.
• **Insufficient evidence is a stop, not a prompt to improvise.** Tag the roster role

that owns the decision; silence never converts to permission.

Skill routing

| Work in front of you | Skill | |---|---| | New repo, or operating model install/repair | `operating-model-bootstrap` | | Multi-track epic, or "which skill applies?" | `delivery-orchestrator` | | An agreed goal to drive to a working, merged outcome while the operator is away | `get-it-done` | | Close out the in-flight set to a clean baseline (the set does not grow) | `wrap-it-up` | | The machine is slow, tests or browser skills left processes behind | `system-performance-guardrail` | | Is everything live, any errors this week, the weekly SRE checkup of a GCP project | `cloud-checkup` | | Is the page fast enough, Core Web Vitals, why is this route slow | `frontend-performance-audit` | | Vision, requirements, user journeys and product acceptance | `product-owner` | | Material strategic, cost/risk or operating ownership decision | `cxo-oversight` | | Acceptance coverage and executable user-path checks | `test-strategy` | | Significant technical decision or ADR | `the-architect` | | New feature, epic, or change — plan before code | `spec-first-delivery` | | High-stakes decision, or before claiming done | `adversarial-gate` | | Agent output feeding a decision, store, or another agent | `domain-validator` | | Any PR or agent-generated code before commit | `pr-reviewer` | | Anything about to ship to a real environment | `release-readiness` | | CI triggers, Actions billing, issues, labels, branch protection, or release-tag workflow | `github-manager` | | Release process governance: SemVer, ADR, changelog, release authority | `release-manager` | | Enterprise policy, compliance, governance, or approved-vendor alignment | `governance-guardrail` | | Status, standup, or situation report | `sitrep` | | Plugin-directory, marketplace, or curated-list submission | `plugin-submission` | | LLM/cloud cost estimate or architecture with LLM calls | `cost-guardrail` | | Google ADK multi-agent design | `adk-expert` | | Any cloud-vendor workload (GCP, AWS, Azure, Alibaba Cloud) | `cloud-expert` (`the-architect` routes) | | Adding or reviewing an MCP server | `mcp-server-scaffold` |

Companion plugins

Agent-craft capabilities may be provided by installed companion plugins instead of these skills — see `INTEGRATIONS.md` for the evaluated map (simplicity discipline, TDD methodology, frontend design review, and similar craft lanes).

• Route craft work to an installed companion when the project profile names one as the

provider. Do not re-implement a capability an installed companion already provides.

• C