boshu2/agentops

# Implement

Execute exactly one bounded experiment described by the resolved bead or caller
intent. Implement owns subject edits and factual evidence. It does not create a
second planning record or a model-authored candidate packet.

## Workflow

1. Read the intent, acceptance, and scope from their existing source. A runtime
   may snapshot and hash that source automatically for drift detection.
2. Run the declared first acceptance check before changing behavior. RED-first
   applies only when acceptance is behavioral: preserve evidence that the check
   fails for the expected missing behavior. Relocations, doc merges, and pure
   refactors need no failing-check ritual — record an honest green pre-change

# Implement

Execute exactly one bounded experiment described by the resolved bead or caller
intent. Implement owns subject edits and factual evidence. It does not create a
second planning record or a model-authored candidate packet.

## Workflow

1. Read the intent, acceptance, and scope from their existing source. A runtime
   may snapshot and hash that source automatically for drift detection.
2. Run the declared first acceptance check before changing behavior. RED-first
   applies only when acceptance is behavioral: preserve evidence that the check
   fails for the expected missing behavior. Relocations, doc merges, and pure
   refactors need no failing-check ritual — record an honest green pre-change

# Validate

Independently judge one exact subject against the acceptance in its existing
bead or caller source, return one semantic result, and stop. Validate is the
sole `verdict.v2` writer when persistence is requested. It never asks the model
to reconstruct Plan or Candidate packets.

## Preconditions

- The subject is a nonempty implementation candidate: the manifest lists at
  least one entry, and `store-verdict` refuses an empty one. Plans, audits,
  reviews, and other control artifacts are not completion subjects unless the
  caller explicitly requested document review.
- The intent source is available as a caller-owned artifact or runtime-owned

# Using GC

Use Gas City only when the caller explicitly selects it. Treat it as a
replaceable execution adapter, not a correctness or completion boundary.

## Choose the factory first

AgentOps supports both Gas City and the
[Agentic Coding Flywheel](https://agent-flywheel.com) as external
software-factory runtimes. Use this skill only for Gas City. If the caller
selects the Flywheel, use its native workflow instead of wrapping it in Gas
City.

AgentOps supplies skills and evidence contracts to either factory. It does not

# Agent Native

Launch and observe caller-selected agent sessions as explicit roles, and return
runtime facts per packet. Execution does not validate output: no adapter issues
a binding verdict or turns factory completion into delivery or validation proof.
[Orchestrate](../orchestrate/SKILL.md) decides what to dispatch and when; this
skill launches and observes.

## Before launch, and while running

- **Validate the whole batch first.** Every packet needs its packet identity,
  caller intent, role, selected executor, workspace, starting commit,
  authorized source scope, evidence destination, all transitive effects, the
  actions it must not take (such as push, merge, history rewrite, tracker or

# AGY Native

Run a supplied packet in AGY (Antigravity) only when the caller explicitly
selects that runtime. Scope the run to the supplied workspace and packet,
return runtime evidence, and stop.

## Before launch

1. **Read the live surface.** The CLI changes faster than skill text.
   Re-checked on 2026-10-25 against Claude Code 2.1.309, codex-cli 0.163.0, AGY 1.4.7, gc edge 97503b2 (with Gas City v1.5.1 docs and source), bd 1.3.1 and ao 3.11.0.
   Run `agy --help` for flags, `agy changelog` for behavior the help omits,
   and `agy models` for ids. That list includes Claude and GPT-OSS: a Gemini
   or cross-family run needs a `gemini-*` id.
2. **Absent means stop.** If `agy` is missing or its help cannot be read,

# Architecture

Architecture finds where a codebase's structure makes change expensive and
proposes a better shape: a deeper module, a seam where behavior has to vary, or
a boundary moved to where the domain language changes. It analyses and
proposes; it edits nothing. Neighbours: [Refactor](../refactor/SKILL.md)
executes one behavior-preserving transformation, [Implement](../implement/SKILL.md)
changes behavior, [Plan](../plan/SKILL.md) slices a chosen change,
[Domain](../domain/SKILL.md) settles what terms mean per context, and
[Review](../review/SKILL.md) advises on an existing plan or diff.

## Vocabulary

Use these meanings in every proposal so the caller can compare them.

# Claude Exec — one-shot runtime adapter

Run one caller-supplied prompt through Claude Code print mode and capture the
result, only when the caller selects Claude: the native agent stays the
default and batches belong to `agent-native`. Flags match `claude --help` for
2.1.309; recheck it on other versions. Re-checked on 2026-10-25 against Claude
Code 2.1.309, codex-cli 0.163.0, AGY 1.4.7, gc edge 97503b2 (with Gas City
v1.5.1 docs and source), bd 1.3.1 and ao 3.11.0.

## Failure modes of a quick `claude -p`

1. **Inherited posture.** A plain run loads the user's settings, hooks,
   plugins, MCP servers and CLAUDE.md; a settings `bypassPermissions` default
   held even under `--safe-mode`. Use the clean flags below and set `--tools`
   and `--permission-mode` to the task's effects. They drop settings files,

# Codex Exec — one-shot runtime adapter

Run exactly one caller-supplied Codex prompt as one process and capture its
result. This skill does not choose work, retry, validate or continue.

## Rules that change the command

- **Sandbox from declared effects.** `-s read-only` for review or analysis,
  `workspace-write` only for authorized edits, and network or wider access only
  when the caller explicitly requires those effects. "In case it needs it" is
  not a declared effect. `-s` limits only Codex's shell commands; the user's
  `config.toml` still starts its MCP servers. For review and CI add
  `--ignore-user-config` (auth still loads) and `--ephemeral`, or report the
  inherited MCP servers as undeclared effects. A permission denial inside the
  run (`EPERM`, "Operation not permitted") shows only what the mode blocks, not

# Council

Council is an optional judgment strategy for hard questions where contrasting
perspectives can expose alternatives, assumptions, or missed evidence. Use it
when the caller selects multiple views for brainstorming, architecture or
planning, or validation. Name the uncertainty that makes the additional
contexts useful; routine work needs no council. Neighbours: one opinion or
look-over is [Review](../review/SKILL.md), one adversarial challenge of a plan
is [Premortem](../premortem/SKILL.md), one consequential choice for Plan is
[Idea Genie](../idea-genie/SKILL.md), and an acceptance verdict is
[Validate](../validate/SKILL.md).

## Rules that decide the synthesis

# Craft Goal

Craft or lint a goal prompt: the contract a long-running goal runtime follows
over a bead graph, picking each next experiment (one build bead) until a
frozen finish line is proven or a limit stops it. The number of experiments
need not be known in advance. A goal is safe when success is decidable, every
experiment is bounded, evidence keeps its provenance, and the authorization
envelope cannot silently renew itself.

**Authority boundary.** The emitted prompt and safety report are inert
caller-owned text. Crafting creates no goal, starts no runtime, mutates no
bead and confers no standing authorization. The prompt drives work only when
a caller pastes it into their own goal runtime, under their own authority and
within the non-renewing envelope they set. Craft Goal reads tracker state when

# Doc

Write or update the documentation the caller needs, grounded in the current
repository and its accepted intent. A small explanation needs no interview,
coverage ledger or separate report. Select only the mode relevant to the task.

## Modes

| Need | Scope and reference |
|---|---|
| Explain an API, command, code-map or architecture | Inspect its consumers and source; use [code/API guidance](references/default-mode.md) or the [codebase report](references/architecture-report.md) when useful. |
| Create or improve a README | Lead with the user's problem and a working first-use path; preserve useful depth. See [README craft](references/readme-craft.md). |
| Check an advertised install, upgrade or first-success path | Follow the selected package and current instructions in an authorized disposable environment. See [developer journey](references/developer-journey.md). |
| Audit or scaffold OSS documentation | Compare existing docs with the requested pack. Create missing files; revise existing files only within the authorized request. See [OSS pack](references/oss-pack.md). |
| Initialize missing entry documents | Create only explicitly requested missing files; report existing paths as skipped. See [setup examples](references/bootstrap/examples.md). |

# Domain

Two independent uses: [vocabulary work](#vocabulary-work) makes a term, name or
rule boundary precise enough for acceptance examples, code and conversation; a
[standards lookup](#standards-lookup) finds the language, data-format, risk or
test-design standard for a change. Neither needs the other. [Plan](../plan/SKILL.md)
owns unified discovery and resumption; Domain resolves only the needed
vocabulary or rule boundary and returns it to the existing intent.

## Vocabulary work

1. **Cite the existing owner.** Find the vocabulary owner in the caller's
   instructions, domain docs or contracts and read only the relevant terms. A
   lookup is read-only. With no owner, label each definition as observed in
   code or proposed.

# Ergonomics

Judge a tool surface from the position of its most literal consumer, an AI
agent: a CLI, HTTP API, MCP or agent tool, SDK or library, or a proposed design
for one. A human developer is the second consumer and is usually served by the
same fixes. Neighbours: threats are [Security](../security/SKILL.md); help text
and READMEs are [Doc](../doc/SKILL.md); lasting proof is [Test](../test/SKILL.md);
applying fixes is [Implement](../implement/SKILL.md); acceptance is
[Validate](../validate/SKILL.md).

## The literal reader

An agent sees only text, exit codes and structured output. It has no screen,
no colour cue and often no terminal or open stdin. It copies the printed next
step and runs it as written. It cannot ask what a message meant. When something

# Idea Genie

One canonical root for idea work: elicit an evidence-grounded portfolio of
options, or challenge a consequential idea with sealed independent
perspectives. Both modes explore and advise; neither selects, schedules,
tracks, implements, or validates work.

## Modes

| Trigger phrases | Mode | Output contract |
|---|---|---|
| "idea genie", "what should we build next", "brainstorm options", "supported opportunities" | elicit | `idea-portfolio.v1` |
| "challenge this idea", "compare independent proposals", "stress-test a one-way door" | duel | `idea-challenge.v1` |

# Implement

Implement the accepted outcome. Repair ordinary known defects directly. Use the
existing intent; a clear edit needs no Plan first. Implement owns source changes
and factual checks. Read changed paths from Git (`git status --porcelain`,
`git diff --name-only <base>`), never from memory;
`ao provenance manifest --root <repo>` with one `--include <path>` per declared
path digests only the paths you declare and runs no Git. Copy check results from the command output.

## Rules that decide the result

- **Fix the cause, not the oracle.** Never loosen an assertion, tolerance,
  golden, fixture or suppression, or substitute a mock or placeholder, to turn
  a check green; nor change what the check runs against: code that acts

# Interview

Shape a big outcome with the caller, one question per turn, before agents run
alone: you look up facts; the caller makes choices and supplies what only they
know. Interview creates nothing new (no goal, bead or file), changes no status,
claim or closure, and only appends notes to an existing intent source
([Show the state](#show-the-state)). To test a plan, design or decision the
caller already holds, see [a held plan](references/stress-test.md#a-plan-the-caller-already-holds).

## Each turn

1. **Look it up** in the tracker, docs and code first. Ask the caller only for
   choices (outcome, proof, non-goals, authority, budgets, priorities, risk
   tolerance) and for facts no source holds: what they tried or ruled out,

# Memory

Use maintained experience only when it changes an action. Memory is optional:
no mandatory recall at RPI entry, lesson at completion, worksheet, page quota or
background mining. A trivial edit can proceed directly to implementation.

## Rules for any saved lesson or rule

Apply these whenever a request would save or promote a lesson, including a
request to turn an incident into a rule for an instruction file:

1. **Look for an existing entry first.** Search the selected `.context/` pages,
   external topic pages or the target instruction file (`AGENTS.md`,
   `CLAUDE.md`, a team rules file). Amend the entry that already covers the

# Navigate

Pick the next wave (the ready beads run together next) on a bead graph and
keep the graph honest toward its frozen acceptance. The root epic holds
acceptance; each child build bead is one experiment; a decision bead goes to
the resolver it names ([Foggy epics](#foggy-epics)). Navigate picks and
records, and never edits acceptance, dispatches, judges or closes:
[Plan](../plan/SKILL.md) shapes, [Orchestrate](../orchestrate/SKILL.md)
dispatches, native execution (the caller's coding agent and shell) or an
optional [RPI](../rpi/SKILL.md) run builds, [Validate](../validate/SKILL.md)
judges, and Craft Goal owns the prompt and HOLD (the goal's stop on a
declared trigger, so the cause can be examined before more work runs).

**One pass**, when a person asks what is next on an epic: steps 1 and 2 plus

# Orchestrate

Coordinate caller-authorized work through its existing tracker and runtime; a
clear task needs zero mandatory skills. The tracker owns assignments and
dependencies, the runtime owns running contexts and bounds, and repository
policy owns integration and delivery. Orchestrate decides what each worker does
next. [Agent Native](../agent-native/SKILL.md) launches and observes workers;
[Navigate](../navigate/SKILL.md) picks the wave on a bead graph toward frozen
acceptance and records verdicts.

## Before any dispatch

- **Finished is not done.** Exit 0, a pushed branch, a closed tracker item or a
  worker saying "done" makes a candidate. It still owes its checks, integration

# Plan

Shape missing intent into one actionable slice, then stop. A clear change can
proceed directly; load a specialist only for the question it answers.
Prefer the caller's tracker, if any; otherwise use the conversation or
supplied text. Supplied advice, such as an [Idea Genie](../idea-genie/SKILL.md)
portfolio or challenge, is evidence to weigh, never a decision.

## A plan meets these rules

1. **One slice, not a roadmap.** Shape the narrowest change that produces an
   observable result end to end, through every layer it touches. No phases,
   no layer-by-layer breakdown, no backlog: later work stays one coarse line
   each until new evidence makes it the next slice. When several slices could

# Postmortem

Answer an explicit retrospective causal question about a completed or stopped
goal, session, change or incident from its actual intent, outcome and judgment evidence.
Neighbours: how a plan not yet run could fail is [Premortem](../premortem/SKILL.md);
whether a finished change meets acceptance is [Validate](../validate/SKILL.md).

## First check: correlation or cause?

Treat every causal statement as a hypothesis, including the one the caller
arrives with. Promoting a claim from correlation to cause requires all three:

- a stated mechanism: the specific path by which the condition produced the
  outcome, in terms a reader could check against the subject;

# Premortem

Premortem is an optional plan-challenge strategy. It asks one fresh context to
identify concrete ways the resolved bead or caller intent could fail before implementation.
It is not part of the required RPI sequence and does not authorize readiness.
[Plan's shared challenge method](../plan/references/challenge.md) owns optional
exchange, dispatch and stopping rules; when no fresh context can be started,
step 2's labelled self-judged fallback replaces its no-stand-in rule here.
Premortem owns the three checks below. Neighbours: general advice is
[Review](../review/SKILL.md), acceptance of a finished change is
[Validate](../validate/SKILL.md), and several independent views are
[Council](../council/SKILL.md).

Run the checks in this order and report findings in the same order: a finding

# Refactor — one structural experiment

Refactor changes structure while preserving observable behavior. It performs one
caller-selected transformation and reports the result. "Behavior-preserving" is
a claim to prove with before/after checks, never to assert.

## What counts as behavior

Unless the caller explicitly excluded a surface, all of these must survive:

- **Messages and exit codes.** Error and output text compares byte-for-byte;
  exit codes, error types and which input raises which error stay the same.
  Scripts and callers parse them. Preserve an inconsistent message and report
  it; normalizing it is a behavior change.
- **Differences between near-duplicates.** When merging duplicated branches,

# Research

Answer the caller's bounded question with cited evidence. Choose ordinary
investigation, claim checking, a claimed-state audit, decision lineage,
repository tracing or pattern evidence according to the question; these are
optional modes, not a sequence. A quick answer needs no report file.
[Plan](../plan/SKILL.md) owns unified discovery and resumption when the question
is part of shaping a change; return this cited answer to that existing intent
without restarting its interview or taking over caller choices.

## Evidence rules

- **One lineage counts once.** Copies, ports and repeated quotations of one
  upstream source are a single exemplar, however many files or reports carry
  them. Check provenance before counting instances as independent, and stop

# Reverse Engineer

Reverse-engineer an external system into two things: a **teardown** (feature
inventory, a registry of where to read, CLI and contract specs, optionally a
security audit) and a **steal-map** (the decision: what to adopt into our
surfaces and what to leave behind). A decision row that must cite evidence can
be re-checked by anyone; a decision made from impressions cannot be re-checked
by its own author. Deciding from a competitor's README is the failure this
skill exists to prevent.

## ⚠<U+FE0F> Constraints — Hard Guardrails (MANDATORY)

- Only operate on code/binaries you own or have **explicit written authorization** to analyze — this matters because unauthorized teardown is the legal/IP line.
- Do not provide steps to bypass protections/ToS or to extract proprietary source/system prompts.
- Do not output reconstructed proprietary source or embedded prompts (index only; redact in reports) — to prevent reproducing protected IP.

# Review

Give useful, supported advice on the caller's plan, design or change, in the
existing conversation. Review does not accept the subject, issue `PASS`, `FAIL`
or `NOT_PROVEN`, or author `verdict.v2`. Neighbours: how a plan could fail is
[Premortem](../premortem/SKILL.md); whether a stated claim holds is
[Research](../research/SKILL.md#claimed-state-audit); an acceptance verdict is
[Validate](../validate/SKILL.md); several independent views are
[Council](../council/SKILL.md).

## Rules an unaided review misses

- **Advice is not acceptance.** Never present advice, agreement or a no-finding
  result as acceptance, even when the caller offers to skip independent review

# RPI

Own the authorized outcome through finish. RPI (research, plan, implement) is
one native pass, not fixed phases: use the native coding agent and shell.
BD or the caller's tracker owns work and handoffs; Git owns content and
delivery. AgentOps supplies a small charter and one fresh judgment where a
mistake is costly, not a scheduler.

## Operating charter

1. Use the existing accepted outcome, scope and real bounds. A clear change
   needs no Plan, Recall or Learn worksheet. Resolve uncertainty only when it
   could change the implementation or acceptance decision.
2. Take the smallest acceptance-advancing action. [Plan](../plan/SKILL.md)

# Security Skill

> **Purpose:** Find and report security weaknesses in code, scripts, authorized binaries, and repo-managed prompt surfaces, with honest coverage.

Use this skill for a caller-requested security review of code or of a plan or design before code exists, a repository scan, authorized binary assurance, dependency risk, secrets, or offline prompt-surface redteam.

## Critical Constraints

- Scan only repositories, binaries, and prompt surfaces the operator owns or is explicitly authorized to assess. **Why:** a security review does not grant access to third-party systems or proprietary material.
- Keep collection read-only by default; do not exfiltrate secrets, execute destructive payloads, or mutate policy/baselines to manufacture green. **Why:** the assessment must not become the incident or erase its evidence.
- Treat missing/error scanners as a coverage gap, never a clean finding; use `--require-tools` when complete tool coverage is required. **Why:** absent evidence is not evidence of absence.
- Use the current agent and local shell; do not start another runtime or orchestration substrate unless explicitly requested. **Why:** repository scanning is a bounded operation, not permission to fan out.
- Report findings and coverage gaps, then stop. Remediation, risk acceptance,
  reruns, promotion, and any ship or merge call are caller decisions. Asked
  whether to ship, merge or deploy, give the findings and coverage, then say in

# Skill Builder

Create, repair, audit or export one canonical skill package, or turn supported
expertise into a small authoring proposal.

## Decide whether to create anything

Apply these before any creation step, including when the request already names
the new skill or file it wants:

1. **Find the existing owner.** Search skills, references, checklists and
   instruction files for one that already handles the behavior. Extend that
   owner rather than adding a root.
2. **Count independent occurrences.** A new skill, gate, library or workflow
   needs three independently evidenced real occurrences and a successful

# Skill Eval

Answer one named maintenance decision: **retain, revise, remove, or insufficient
evidence**. Choose the measurement that can answer that decision, use the caller's
accepted cases and resource envelope, make one scoped recommendation, and stop.
A completed evaluation does not require a positive difference.

This is an optional specialist: the selected runner owns execution and bounds,
and its native results own the measurements.

## Rules that decide the answer

- **Count every attempt.** Keep failed, crashed, interrupted, blocked, abandoned,
  missing and infrastructure-invalid attempts in the all-attempt accounting. A

# Test

Write or strengthen tests for a named behavior. Use existing tests directly when
the task is only to run a known suite; this skill is not a required wrapper.
A test is useful when it distinguishes an accepted outcome from a plausible
failure, not merely when it executes the implementation. A green test is
evidence for the caller's decision, never the test author's merge approval;
the binding verdict belongs to [Validate](../validate/SKILL.md).

## Modes

| Mode | Use when | Result |
|---|---|---|
| `generate` | Existing behavior needs tests | Useful tests and focused/suite results |
| `coverage` | The caller asks to find or fill gaps | Before/after coverage, valuable tests and remaining risks |

# Triage

Turn one incoming report (bug report, feature request, external PR, feedback,
operational alert, support message), or a small batch, into a supported
decision and, for accepted or likely-accepted work, a brief an agent can act
on without this conversation. Triage is intake, before planning. It
recommends; the maintainer decides. [Plan](../plan/SKILL.md) shapes accepted
work into a slice; [Security](../security/SKILL.md#triage) owns scanner
findings.

## Rules an unaided triage misses

- **Observe before you brief.** Confirm the fetch returned the whole thread,
  not only the opening post, and read the latest comments closely: they often

# Using GC

Use Gas City only when the caller explicitly selects it. It is a replaceable
execution adapter whose completion is never AgentOps acceptance or delivery
proof; [Orchestrate](../orchestrate/SKILL.md) owns that rule for every factory.
If the caller selects the [Agentic Coding Flywheel](https://agent-flywheel.com)
instead, follow its [native workflow](https://agent-flywheel.com/complete-guide).

## The operator lane

While a city runs work, the operator lane into it is a closed set:

- author source intent beads;
- `gc mail` to the Mayor, for work dispatch and for city tending;

# Validate

Freshly judge one finished candidate against its original acceptance, return
`PASS`, `FAIL`, or `NOT_PROVEN` with criterion-level evidence, and stop.
Neighbours: advice or a second look is [Review](../review/SKILL.md); whether a
stated claim holds is [Research](../research/SKILL.md#claimed-state-audit). This file
carries every rule the judgment needs. Linked files, including
[RPI boundaries](../rpi/references/boundaries.md) and
[mechanics](references/mechanics.md), add depth only: if one cannot be read,
judge from this file and say which was unavailable.

## Rules that decide the verdict

- The author cannot issue a binding PASS, and advisory findings, such as a

# Agent Native

Launch and observe caller-selected agent sessions as explicit roles, and return
runtime facts per packet. Execution does not validate output: no adapter issues
a binding verdict or turns factory completion into delivery or validation proof.
[Orchestrate](../orchestrate/SKILL.md) decides what to dispatch and when; this
skill launches and observes.

## Before launch, and while running

- **Validate the whole batch first.** Every packet needs its packet identity,
  caller intent, role, selected executor, workspace, starting commit,
  authorized source scope, evidence destination, all transitive effects, the
  actions it must not take (such as push, merge, history rewrite, tracker or

# AGY Native

Run a supplied packet in AGY (Antigravity) only when the caller explicitly
selects that runtime. Scope the run to the supplied workspace and packet,
return runtime evidence, and stop.

## Before launch

1. **Read the live surface.** The CLI changes faster than skill text.
   Re-checked on 2026-10-25 against Claude Code 2.1.309, codex-cli 0.163.0, AGY 1.4.7, gc edge 97503b2 (with Gas City v1.5.1 docs and source), bd 1.3.1 and ao 3.11.0.
   Run `agy --help` for flags, `agy changelog` for behavior the help omits,
   and `agy models` for ids. That list includes Claude and GPT-OSS: a Gemini
   or cross-family run needs a `gemini-*` id.
2. **Absent means stop.** If `agy` is missing or its help cannot be read,

# Architecture

Architecture finds where a codebase's structure makes change expensive and
proposes a better shape: a deeper module, a seam where behavior has to vary, or
a boundary moved to where the domain language changes. It analyses and
proposes; it edits nothing. Neighbours: [Refactor](../refactor/SKILL.md)
executes one behavior-preserving transformation, [Implement](../implement/SKILL.md)
changes behavior, [Plan](../plan/SKILL.md) slices a chosen change,
[Domain](../domain/SKILL.md) settles what terms mean per context, and
[Review](../review/SKILL.md) advises on an existing plan or diff.

## Vocabulary

Use these meanings in every proposal so the caller can compare them.

# Claude Exec — one-shot runtime adapter

Run one caller-supplied prompt through Claude Code print mode and capture the
result, only when the caller selects Claude: the native agent stays the
default and batches belong to `agent-native`. Flags match `claude --help` for
2.1.309; recheck it on other versions. Re-checked on 2026-10-25 against Claude
Code 2.1.309, codex-cli 0.163.0, AGY 1.4.7, gc edge 97503b2 (with Gas City
v1.5.1 docs and source), bd 1.3.1 and ao 3.11.0.

## Failure modes of a quick `claude -p`

1. **Inherited posture.** A plain run loads the user's settings, hooks,
   plugins, MCP servers and CLAUDE.md; a settings `bypassPermissions` default
   held even under `--safe-mode`. Use the clean flags below and set `--tools`
   and `--permission-mode` to the task's effects. They drop settings files,

# Codex Exec — one-shot runtime adapter

Run exactly one caller-supplied Codex prompt as one process and capture its
result. This skill does not choose work, retry, validate or continue.

## Rules that change the command

- **Sandbox from declared effects.** `-s read-only` for review or analysis,
  `workspace-write` only for authorized edits, and network or wider access only
  when the caller explicitly requires those effects. "In case it needs it" is
  not a declared effect. `-s` limits only Codex's shell commands; the user's
  `config.toml` still starts its MCP servers. For review and CI add
  `--ignore-user-config` (auth still loads) and `--ephemeral`, or report the
  inherited MCP servers as undeclared effects. A permission denial inside the
  run (`EPERM`, "Operation not permitted") shows only what the mode blocks, not

# Council

Council is an optional judgment strategy for hard questions where contrasting
perspectives can expose alternatives, assumptions, or missed evidence. Use it
when the caller selects multiple views for brainstorming, architecture or
planning, or validation. Name the uncertainty that makes the additional
contexts useful; routine work needs no council. Neighbours: one opinion or
look-over is [Review](../review/SKILL.md), one adversarial challenge of a plan
is [Premortem](../premortem/SKILL.md), one consequential choice for Plan is
[Idea Genie](../idea-genie/SKILL.md), and an acceptance verdict is
[Validate](../validate/SKILL.md).

## Rules that decide the synthesis

# Craft Goal

Craft or lint a goal prompt: the contract a long-running goal runtime follows
over a bead graph, picking each next experiment (one build bead) until a
frozen finish line is proven or a limit stops it. The number of experiments
need not be known in advance. A goal is safe when success is decidable, every
experiment is bounded, evidence keeps its provenance, and the authorization
envelope cannot silently renew itself.

**Authority boundary.** The emitted prompt and safety report are inert
caller-owned text. Crafting creates no goal, starts no runtime, mutates no
bead and confers no standing authorization. The prompt drives work only when
a caller pastes it into their own goal runtime, under their own authority and
within the non-renewing envelope they set. Craft Goal reads tracker state when

# Doc

Write or update the documentation the caller needs, grounded in the current
repository and its accepted intent. A small explanation needs no interview,
coverage ledger or separate report. Select only the mode relevant to the task.

## Modes

| Need | Scope and reference |
|---|---|
| Explain an API, command, code-map or architecture | Inspect its consumers and source; use [code/API guidance](references/default-mode.md) or the [codebase report](references/architecture-report.md) when useful. |
| Create or improve a README | Lead with the user's problem and a working first-use path; preserve useful depth. See [README craft](references/readme-craft.md). |
| Check an advertised install, upgrade or first-success path | Follow the selected package and current instructions in an authorized disposable environment. See [developer journey](references/developer-journey.md). |
| Audit or scaffold OSS documentation | Compare existing docs with the requested pack. Create missing files; revise existing files only within the authorized request. See [OSS pack](references/oss-pack.md). |
| Initialize missing entry documents | Create only explicitly requested missing files; report existing paths as skipped. See [setup examples](references/bootstrap/examples.md). |

# Domain

Two independent uses: [vocabulary work](#vocabulary-work) makes a term, name or
rule boundary precise enough for acceptance examples, code and conversation; a
[standards lookup](#standards-lookup) finds the language, data-format, risk or
test-design standard for a change. Neither needs the other. [Plan](../plan/SKILL.md)
owns unified discovery and resumption; Domain resolves only the needed
vocabulary or rule boundary and returns it to the existing intent.

## Vocabulary work

1. **Cite the existing owner.** Find the vocabulary owner in the caller's
   instructions, domain docs or contracts and read only the relevant terms. A
   lookup is read-only. With no owner, label each definition as observed in
   code or proposed.

# Ergonomics

Judge a tool surface from the position of its most literal consumer, an AI
agent: a CLI, HTTP API, MCP or agent tool, SDK or library, or a proposed design
for one. A human developer is the second consumer and is usually served by the
same fixes. Neighbours: threats are [Security](../security/SKILL.md); help text
and READMEs are [Doc](../doc/SKILL.md); lasting proof is [Test](../test/SKILL.md);
applying fixes is [Implement](../implement/SKILL.md); acceptance is
[Validate](../validate/SKILL.md).

## The literal reader

An agent sees only text, exit codes and structured output. It has no screen,
no colour cue and often no terminal or open stdin. It copies the printed next
step and runs it as written. It cannot ask what a message meant. When something

# Idea Genie

One canonical root for idea work: elicit an evidence-grounded portfolio of
options, or challenge a consequential idea with sealed independent
perspectives. Both modes explore and advise; neither selects, schedules,
tracks, implements, or validates work.

## Modes

| Trigger phrases | Mode | Output contract |
|---|---|---|
| "idea genie", "what should we build next", "brainstorm options", "supported opportunities" | elicit | `idea-portfolio.v1` |
| "challenge this idea", "compare independent proposals", "stress-test a one-way door" | duel | `idea-challenge.v1` |

# Implement

Implement the accepted outcome. Repair ordinary known defects directly. Use the
existing intent; a clear edit needs no Plan first. Implement owns source changes
and factual checks. Read changed paths from Git (`git status --porcelain`,
`git diff --name-only <base>`), never from memory;
`ao provenance manifest --root <repo>` with one `--include <path>` per declared
path digests only the paths you declare and runs no Git. Copy check results from the command output.

## Rules that decide the result

- **Fix the cause, not the oracle.** Never loosen an assertion, tolerance,
  golden, fixture or suppression, or substitute a mock or placeholder, to turn
  a check green; nor change what the check runs against: code that acts

# Interview

Shape a big outcome with the caller, one question per turn, before agents run
alone: you look up facts; the caller makes choices and supplies what only they
know. Interview creates nothing new (no goal, bead or file), changes no status,
claim or closure, and only appends notes to an existing intent source
([Show the state](#show-the-state)). To test a plan, design or decision the
caller already holds, see [a held plan](references/stress-test.md#a-plan-the-caller-already-holds).

## Each turn

1. **Look it up** in the tracker, docs and code first. Ask the caller only for
   choices (outcome, proof, non-goals, authority, budgets, priorities, risk
   tolerance) and for facts no source holds: what they tried or ruled out,

# Memory

Use maintained experience only when it changes an action. Memory is optional:
no mandatory recall at RPI entry, lesson at completion, worksheet, page quota or
background mining. A trivial edit can proceed directly to implementation.

## Rules for any saved lesson or rule

Apply these whenever a request would save or promote a lesson, including a
request to turn an incident into a rule for an instruction file:

1. **Look for an existing entry first.** Search the selected `.context/` pages,
   external topic pages or the target instruction file (`AGENTS.md`,
   `CLAUDE.md`, a team rules file). Amend the entry that already covers the

# Navigate

Pick the next wave (the ready beads run together next) on a bead graph and
keep the graph honest toward its frozen acceptance. The root epic holds
acceptance; each child build bead is one experiment; a decision bead goes to
the resolver it names ([Foggy epics](#foggy-epics)). Navigate picks and
records, and never edits acceptance, dispatches, judges or closes:
[Plan](../plan/SKILL.md) shapes, [Orchestrate](../orchestrate/SKILL.md)
dispatches, native execution (the caller's coding agent and shell) or an
optional [RPI](../rpi/SKILL.md) run builds, [Validate](../validate/SKILL.md)
judges, and Craft Goal owns the prompt and HOLD (the goal's stop on a
declared trigger, so the cause can be examined before more work runs).

**One pass**, when a person asks what is next on an epic: steps 1 and 2 plus

# Orchestrate

Coordinate caller-authorized work through its existing tracker and runtime; a
clear task needs zero mandatory skills. The tracker owns assignments and
dependencies, the runtime owns running contexts and bounds, and repository
policy owns integration and delivery. Orchestrate decides what each worker does
next. [Agent Native](../agent-native/SKILL.md) launches and observes workers;
[Navigate](../navigate/SKILL.md) picks the wave on a bead graph toward frozen
acceptance and records verdicts.

## Before any dispatch

- **Finished is not done.** Exit 0, a pushed branch, a closed tracker item or a
  worker saying "done" makes a candidate. It still owes its checks, integration

# Plan

Shape missing intent into one actionable slice, then stop. A clear change can
proceed directly; load a specialist only for the question it answers.
Prefer the caller's tracker, if any; otherwise use the conversation or
supplied text. Supplied advice, such as an [Idea Genie](../idea-genie/SKILL.md)
portfolio or challenge, is evidence to weigh, never a decision.

## A plan meets these rules

1. **One slice, not a roadmap.** Shape the narrowest change that produces an
   observable result end to end, through every layer it touches. No phases,
   no layer-by-layer breakdown, no backlog: later work stays one coarse line
   each until new evidence makes it the next slice. When several slices could

# Postmortem

Answer an explicit retrospective causal question about a completed or stopped
goal, session, change or incident from its actual intent, outcome and judgment evidence.
Neighbours: how a plan not yet run could fail is [Premortem](../premortem/SKILL.md);
whether a finished change meets acceptance is [Validate](../validate/SKILL.md).

## First check: correlation or cause?

Treat every causal statement as a hypothesis, including the one the caller
arrives with. Promoting a claim from correlation to cause requires all three:

- a stated mechanism: the specific path by which the condition produced the
  outcome, in terms a reader could check against the subject;

# Premortem

Premortem is an optional plan-challenge strategy. It asks one fresh context to
identify concrete ways the resolved bead or caller intent could fail before implementation.
It is not part of the required RPI sequence and does not authorize readiness.
[Plan's shared challenge method](../plan/references/challenge.md) owns optional
exchange, dispatch and stopping rules; when no fresh context can be started,
step 2's labelled self-judged fallback replaces its no-stand-in rule here.
Premortem owns the three checks below. Neighbours: general advice is
[Review](../review/SKILL.md), acceptance of a finished change is
[Validate](../validate/SKILL.md), and several independent views are
[Council](../council/SKILL.md).

Run the checks in this order and report findings in the same order: a finding