agentic-ops-framework

Use to send a structured handoff / fleet-update / directive-notice / request / ack message to another fleet repo's inbox file. Also use on session start to read incoming messages in your own repo's inbox. Counterpart to AGENT_FEEDBACK.md (outbound-to-fleet); sibling to cross-repo-policy-enforcement (the enforced channel). Messages are informational; for compliance-required changes use cross-repo-policy-enforcement instead.

Use when capturing an IDEA (/idea-capture) or authoring a SPEC.md (/author-spec) under the spec-first model. Owns templates, type selection (fastpath / task / contract / decision), shared schema, citation discipline, IDEA-conversation tactics. Hands off to spec-review for the BLOCKING gate. Do not use to review existing specs (spec-review) or implement approved specs (implementation-execution).

the studio lifecycle index for non-trivial work — the 13-phase pipeline (IDEA → SPEC → review → approve → decompose → dispatch → execute → cross-validate → verify → close + capture-after / fastpath exception). Routes to per-phase skills (spec-authoring, spec-review, approved-spec-decomposition, implementation-execution, verification, spec-evidence-governance, fast-path). Read directly when you need the overall procedure; otherwise invoke the specific phase skill.

Use when an agent hits friction, confusion, a bug, or a fleet-policy misalignment they cannot resolve from existing docs. Appends a structured entry to AGENT_FEEDBACK.md (per repo) for owner triage and conversion into fleet directives. Outbound-to-fleet channel; counterpart to agent-inbox (inbound handoffs) and fleet-enforce (compliance directives). Replaces the ad-hoc 'agent complains verbally' channel with a durable, auditable surface.

Use to audit or improve AGENTS.md / CLAUDE.md / GEMINI.md / WORKFLOW.md against the canonical fleet entry-doc pattern. Fires when authoring or revising entry docs, when audit-entry-docs.sh flags drift, or when a new repo joins the fleet and needs entry docs scaffolded. Do not use to write product documentation — entry docs are agent-control content per OPERATING_MODEL Source Of Truth.

Use when the owner has explicitly authorised a small, single-component, reversible change that does not warrant full IDEA→SPEC→review→approve ceremony. Skips the 13-phase lifecycle in favour of a single capture-after SPEC at status: closed in the same commit as the work. ONLY valid when ALL thresholds in this skill's 'Thresholds' section are met; otherwise escalate to task/contract/decision.

Use as the BLOCKING per-type quality gate after authoring or revising an IDEA.md or SPEC.md. Selects Task/Contract/Decision bar from front-matter, runs lint-spec.sh (REQUIRED for Contract), emits a Quality Gate Result, transitions status to needs-revision or approved-pending-owner. Never sets status: approved (owner-only). Do not use to author specs — use spec-authoring.

BLOCKING. Use after a SPEC.md is approved and before in-execution to emit one TASK.md per executable slice into specs/<id>/tasks/. Each TASK.md binds a tracker issue 1:1, carries primary/cross-validation/verification model lanes, and gates the parent SPEC's transition approved -> decomposed -> in-execution. Tasks become the source-of-truth dispatchable units; agents and autonomous dispatch runners anchor on them.

Use to prepare a TASK.md slice for autonomous dispatch by an issue-tracker-driven runner (OpenAI Symphony, equivalent CLI runners, or your in-house dispatcher). Checks WORKFLOW.md fleet-body shape, issue eligibility, per-issue workspace isolation, runner settings, and observability expectations. Do not use for interactive sessions — interactive agents do not require dispatcher binding.

Use when the owner asks for caveman, terse, compressed, or no-filler communication. Opt-in response mode that reduces prose while preserving evidence, safety, exact technical content, and approval checkpoints.

Use for reviewing local diffs, branches, or PRs. Prioritises bugs, regressions, missing tests, unsafe assumptions, and broken repo contracts over surface polish. Do not use to author or review SPEC.md / IDEA.md artefacts — use spec-review for that BLOCKING gate.

Use to author + apply structured policy directives that propagate from one source-of-truth policy repo to N child repos in a fleet. Each directive carries a verbatim compliance check; the audit script scans each target repo and reports pass / fail. Counterpart to cross-repo-informational-channel (the informational sibling). Authoring this skill ONLY from the source policy repo; child repos receive and comply, they do not issue.

Use when debugging a failure, flaky behavior, regression, broken command, or unclear root cause. Builds a fast deterministic feedback loop before fixing.

Use when implementing an approved SPEC.md or a TASK.md slice (after decomposition). Keeps edits scoped to approved scope, preserves user work, updates directly coupled tests/docs, surfaces (does not silently swallow) scope drift. Requires SPEC at status: approved (owner-set) or later. Do not implement against draft / needs-revision / approved-pending-owner specs.

Use to spin up an isolated parallel worktree for a TASK.md slice or a cross-family review of an in-flight PR, then bind the framework's lifecycle gates (lint-spec, acceptance_commands, spec-evidence) to the worktree's lifecycle. Pattern is git-worktree-native; pluggable wrapper (e.g., the `wt` CLI from worktrunk.dev) is RECOMMENDED but not required. Owner-led parallel mode only — autonomous dispatch uses per-issue workspaces from its own runner.

Use when preparing commits, PRs, release handoff, or merge cleanup. Enforces explicit staging, conventional commits, PR evidence, and worktree hygiene.

Use at the start of work in any repo to build a current, cited map of instructions, repo state, verification gates, active plans, and likely risk before editing.

Use to convert durable lessons from a completed task into spec evidence candidates — claims with scope, evidence citation, confidence, and a suggested route. Fires after a SPEC reaches status: verified, after a substantial review, or after incident resolution. Do not write trusted shared memory directly; emit candidates for owner triage only.

Use when implementing a behavior change (feature, bug fix) where a runnable test can describe the expected behavior. Write the check first (red), implement (green), refactor. Do not use for refactors that preserve behavior — use implementation-execution alone.

Use before reporting done. Runs the narrowest relevant checks first, then the repo gate when warranted, and records fresh evidence plus residual risk.