@stdd/plugin 0.9.1 → 0.10.0

package/runtime/method/reference-integration.md

@@ -71,6 +71,15 @@ syntax when both hosts are selected. The append-system file is user-owned;
 init maintains only its marked STDD section and saves the generated source as
 `.stdd/PI-snippet.md`.
 
+Every host's managed instructions expose five mandatory routes in native
+syntax: Investigation and Brainstorming are direct read-only routes, Start
+Change is the explicit boundary for persisted or repository-changing action,
+and Implement and Finish Change execute and close that action. The router may
+sequence Investigation → Brainstorming only when unknown current facts
+materially affect future design. It never sends read-only work through Start
+Change or treats ordinary code and docs reading during Brainstorming as a
+separate Investigation.
+
 ## Adoption modes and the universal bundle
 
 STDD has three cumulative adoption modes. **Personal plugin** use installs the
@@ -79,9 +88,9 @@ repository; its lazy skills remain available, while lifecycle integrations stay
 dormant outside a checkout containing `.stdd/`.
 **Shared repository contract** use runs `init` once and commits `.stdd/`, native
 agent routing, and repository policy. **Enforced contract** use explicitly adds
-repository-owned hooks or a CI adapter; ordinary `init` never creates CI, and
-CI reads checkout and review-request facts rather than the private ledger or
-agent state.
+repository-owned hooks, or the two CI commands below to a job the repository
+owns; `init` never creates CI, and CI reads checkout and review-request facts
+rather than the private ledger or agent state.
 
 Repo-local generated skills remain a valid team contract and need no plugin.
 The optional universal bundle at `plugins/stdd/` distributes one generated set
@@ -144,51 +153,45 @@ and do not enumerate either kit or project skills. A local recipe that
 reuses a kit playbook's `name` replaces it: project knowledge outranks the kit.
 Local recipe names must otherwise be unique; init rejects duplicates before
 writing generated state and names both conflicting source files.
-The three skills named by that router (`stdd-start-change`, `stdd-implement`,
-and `stdd-finish-change`) are mandatory; init rejects a profile or local
-override that would make one inactive. Other inactive local overrides still
-shadow their kit playbook intentionally.
-
-## CI adapters
-
-CI integration is an explicit, optional transport adapter around
-provider-neutral CLI contracts. `init` without `--ci` creates no provider file;
-a team may instead place the printed generic commands in an existing quality
-job. Every configured provider runs `stdd check`; a review pipeline pipes its
-live PR/MR description to `stdd check-pr - --base <ref>`. CI uses read-only
-repository and review-request access. It never attempts to prove the agent's
-reasoning, consume the ignored ledger, dispatch workers, or mutate Git: it
-grades only facts derivable from the checkout and review request.
-
-On GitHub, `stdd init --ci github` writes the canonical workflow for these
-gates and installs an explicit supported Node runtime. It fetches the PR body
-live from the API and re-runs on body edits —
-a workflow reading `github.event.pull_request.body` validates a payload
-frozen at trigger time, so an edited body is never re-checked and a re-run
-replays the stale text. The fetch uses node, not the gh CLI — node is
-already required to run stdd, while self-hosted runners often lack gh —
-and the step sets `pipefail`, so a failed fetch fails the gate as a fetch
-error instead of feeding check-pr an empty body that misreports as a
-missing evidence line. `stdd doctor` flags the frozen-payload form, and flags a PR
-template carrying an unquoted evidence label at the start of a line, since
-its placeholder residue would pass the gate on every PR.
-
-On GitLab, `stdd init --ci gitlab` writes an includeable
-`.gitlab/stdd.gitlab-ci.yml` job. It uses the merge-request API to fetch the
-live description, pipes it to `check-pr -`, and passes
-`CI_MERGE_REQUEST_DIFF_BASE_SHA` as the base. The job enables `pipefail`, so
-an API failure fails the gate instead of being mistaken for an empty body.
-Same-project pipelines authenticate with the short-lived `CI_JOB_TOKEN`.
-Because fork merge-request pipelines normally run in the source project, the
-target must allowlist that source for job-token access. A controlled trusted
-fork may instead supply a masked and hidden target-project
-`STDD_GITLAB_READ_API_TOKEN` with only `read_api`; target credentials are
-never safe in an untrusted fork pipeline. Authentication failure names the
-required setup instead of pretending fork access is automatic.
-`stdd init --ci generic` writes no provider file; it prints and records the
-portable command contract for teams to compose into Jenkins, Buildkite, or an
-existing pipeline. Provider templates are adapters, never dependencies of
-the method or public SDK.
+The five skills named by that router (`stdd-investigation`,
+`stdd-brainstorming`, `stdd-start-change`, `stdd-implement`, and
+`stdd-finish-change`) are mandatory; init rejects a profile or local override
+that would make one inactive. Other inactive local overrides still shadow
+their kit playbook intentionally.
+
+## CI
+
+CI is read-only enforcement of checkout and PR facts, composed into whatever
+job the repository already runs. stdd writes no provider configuration: a
+workflow is ordinary infrastructure the team owns, and generating one taught
+nothing the two commands below do not already say. CI never attempts to prove
+the agent's reasoning, consume the ignored ledger, dispatch workers, or mutate
+Git — it grades only facts derivable from the checkout and the review request.
+
+The contract is two commands:
+
+```
+stdd check .
+<live review description> | stdd check-pr - --base <base ref>
+```
+
+Three things a hand-written job has to get right, because they are the part
+that is not obvious:
+
+- **Fetch the description live from the provider API.** An event payload is
+  frozen at trigger time, so a body-only edit is never re-checked and a re-run
+  replays the stale text. On GitHub that means the workflow must not read
+  `github.event.pull_request.body`, and must re-run on the `edited` trigger;
+  `stdd doctor` reports a workflow that validates the frozen payload — a local
+  diagnostic, not part of the `stdd check` gate the job itself runs.
+- **Set `pipefail` on the fetch step.** Otherwise a failed fetch feeds
+  `check-pr` an empty body, which misreports as a missing evidence line
+  instead of as a fetch error.
+- **Check out full history.** `check-pr --base` diffs against the base ref.
+
+`stdd doctor` flags the frozen-payload form, and flags a PR template carrying
+an unquoted evidence label at the start of a line, since its placeholder
+residue would pass the gate on every PR.
 
 ## Local hooks
 
@@ -222,8 +225,10 @@ re-init removes older managed Claude `PostCompact` entries to avoid running the
 ritual twice, while preserving unrelated user hooks. Each integration runs
 `stdd status --local`, which never calls a forge or the network, so every fresh
 context opens with local loop state and the next step already in it — recorded
-state instead of recall. Hook entries are merged into existing valid files
-without duplication. A conflicting Pi extension or invalid JSON settings are
+state instead of recall. When that state is idle, the injected human or JSON
+output is neutral: it says that discussion and read-only work require no task
+instead of prompting task creation. Hook entries are merged into existing valid
+files without duplication. A conflicting Pi extension or invalid JSON settings are
 left untouched and a manual instruction is printed instead. Codex hooks and
 Pi project extensions remain subject to their host's repository trust review.
 

package/runtime/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@stdd/cli",
-	"version": "0.9.1",
+	"version": "0.10.0",
 	"description": "Spec + Test Driven Development — a markdown-first methodology kit for teams building software with AI coding agents",
 	"type": "module",
 	"exports": {

package/runtime/playbooks/brainstorming.md

@@ -1,46 +1,65 @@
 ---
 name: stdd-brainstorming
-description: Shape a fuzzy idea into an agreed behavior contract before any plan or code
-when: A non-trivial change is requested and the requirements, scope, or approach are not yet pinned down.
+description: Explore future behavior and hypothetical approaches without forcing action
+when: Asked for opinions, ideation, future behavior, or a hypothetical implementation approach, with no explicit intent to persist or modify the repository.
 ---
 
 # Brainstorming
 
-The goal is agreement on **what** and **why** before anyone invests in **how**.
-The output is not a document — it is a shared understanding that becomes a
-docs edit and a PR description.
-
-## Process
-
-1. **Understand the current state first.** Read the relevant docs and the code
-   the change will touch. Questions asked from ignorance waste the other
-   side's time; questions asked from knowledge sharpen the idea.
-2. **Ask one question at a time.** Prefer questions that eliminate whole
-   branches of the design space: who is it for, what triggers it, what must
-   never happen, what is explicitly out of scope. When the answer space is
-   enumerable, offer it as a closed choice with your recommendation first —
-   a closed question costs the other side seconds, an open one minutes.
-   Keep open questions for genuinely open design space.
-3. **Challenge scope creep in both directions.** If the idea is bigger than
-   the need, say so and propose the smaller version. If the stated need hides
-   a larger real problem, surface it.
-4. **Propose 2–3 approaches with a recommendation.** For each: one paragraph,
-   the trade-off that actually matters, and what it costs later. Recommend
-   one; do not present a menu without an opinion.
-5. **Converge on the behavior contract.** State the agreed behavior as rules
-   precise enough to test. Confirm them explicitly.
-
-## Output
-
-- The agreed rules become the **docs edit** (the spec) — the first commit of
-  the branch.
-- The rationale, rejected alternatives, and scope decisions go into the
-  **PR description** when the branch opens.
-- Nothing from this conversation is committed as a standalone file.
+Use Brainstorming as an adaptive conversational stance, not a fixed interview.
+The goal is useful clarity about **what** and **why** before anyone commits to
+action. Clarity, deciding not to act, and continuing later are all successful
+outcomes.
+
+## Contract
+
+- Stay read-only: create no task, ledger event, persisted artifact, or
+  repository mutation.
+- Ground the discussion in current docs or code when materially useful. If
+  unknown current facts materially affect the design, invoke
+  `stdd-investigation` first; ordinary reading here is not Investigation.
+- A hypothetical plan shown in chat remains Brainstorming. Explicit intent to
+  persist an artifact or modify the repository crosses into Start Change when
+  no action boundary is active. Within an active change, do not invoke Start
+  Change again; proceed to Planning or Implement as the agreed action requires.
+
+## Conversation
+
+1. **Understand the real need.** Let the user provide context in their own
+   shape. Challenge assumptions and decompose ideas that are larger than the
+   need; apply YAGNI rather than rewarding scope.
+2. **Ask only decision-bearing questions.** Ask at most one per turn, and only
+   when its answer is needed to proceed. Prefer a concise closed choice when
+   the answer space is known. Use a question batch only when the user requests
+   one.
+3. **Offer useful alternatives.** Once context is sufficient, present two or
+   three materially distinct approaches, state the trade-off that matters, and
+   lead with a recommendation. Do not manufacture alternatives when only one
+   approach is sensible.
+4. **Validate incrementally.** Check substantive decisions as they emerge
+   instead of withholding all validation for a final ceremony. An optional
+   recap may state the problem, preferred approach, and unresolved questions.
+
+## Outcomes
+
+Follow the user's intent without forcing a three-option menu:
+
+- **No action:** summarize if useful, then stop. Do not pressure the user to
+  formalize or implement anything.
+- **Defer:** leave a portable backlog note in chat. Persist it only when the
+  user explicitly chooses a destination; if no action boundary is active,
+  invoke `stdd-start-change` before writing it.
+- **Act now:** when the user explicitly chooses persisted or
+  repository-changing action, invoke `stdd-start-change` if no action boundary
+  is active. Within an active change, proceed directly to Planning or Implement
+  as appropriate.
 
 ## Anti-patterns
 
-- Jumping to implementation detail while behavior is still unsettled.
-- Asking multiple stacked questions at once.
-- Writing a "spec document" instead of editing the real docs.
-- Agreeing silently: if you disagree with the direction, say so with reasons.
+- Turning exploration into a mandatory interview or checklist.
+- Asking stacked questions when one decision would unlock progress.
+- Jumping into code or artifact creation without explicit action intent.
+- Treating every conversation as a change that must converge on docs, a plan,
+  or a PR.
+- Presenting options without an opinion, or inventing options to satisfy a
+  quota.

package/runtime/playbooks/delegate-slice.md

@@ -19,11 +19,17 @@ compaction, its recorded events do.
    sandbox when the worker does not need Git authority:
 
    ```bash
-   stdd worker create ../stdd-worker-billing \
+   mkdir -p ../.stdd-workers
+   stdd worker create ../.stdd-workers/billing \
      --frozen "docs/**,migrations/**" \
      --allowed "src/billing/**,test/billing/**"
    ```
 
+   A sandbox cannot live inside the checkout or inside any Git repository, so
+   it goes beside the project — in one hidden container, not as a visible
+   sibling per slice. A directory of projects collects one `.stdd-workers/`
+   however many slices you delegate, and deleting it removes every sandbox.
+
    Use `stdd slice new --frozen ... --allowed ...` only when the worker must
    operate in an existing isolated checkout. `--frozen` names globs the worker
    must not touch. `--allowed` names the only paths it may change. At least one

package/runtime/playbooks/finish-change.md

@@ -1,6 +1,6 @@
 ---
 name: stdd-finish-change
-description: Close an implemented change with independent review, PR evidence, terminal CI, and runtime verification when required
+description: Close an implemented change with the review, PR evidence, terminal CI, and runtime verification its delivery boundary requires
 when: Implementation is locally verified and the change is ready for review, delivery, or handoff.
 ---
 
@@ -9,8 +9,10 @@ when: Implementation is locally verified and the change is ready for review, del
 Close the current checkout in this order:
 
 1. Run the complete affected local verification.
-2. Finish every plan item and run the independent closing review when the
-   capability profile supports it.
+2. Finish every plan item. Run the independent closing review when the plan
+   carries a `[review:]` item or a slice was delegated, and the capability
+   profile supports it; a single slice makes no review claim and is not asked
+   for one.
 <!-- cap:crossCli -->
    `stdd review --via {{STDD_CROSS_CLI_REVIEW_VIA}}` dispatches the other CLI
    read-only and records the verdict in the ledger.
@@ -29,6 +31,11 @@ Close the current checkout in this order:
 6. Run `stdd task finish` only after the requested delivery boundary is
    actually complete.
 
+Steps 3 and 4 apply when that delivery boundary is a PR. A change the user
+asked for as a local edit is complete after step 2 and closes at step 6 —
+opening a PR for it is work nobody requested. Step 5 is not a PR step: any
+delivery carrying a runtime effect gets that verification, PR or not.
+
 <!-- cap:subagents|crossCli -->
 An `approved` verdict freezes the checkout. Anything you notice afterwards —
 a stale comment, a better name, one more edge case — is deferred with

package/runtime/playbooks/investigation.md

@@ -1,7 +1,7 @@
 ---
 name: stdd-investigation
-description: Read-only diagnosis — evidence-backed findings, no changes
-when: Asked to diagnose, triage, or explain behavior WITHOUT changing anything.
+description: Read-only current-state diagnosis — evidence-backed findings, no changes
+when: Asked a factual question about current behavior, or to diagnose or triage it, WITHOUT changing anything.
 ---
 
 # Investigation
@@ -13,9 +13,12 @@ it.
 
 ## Contract
 
-- No file edits, no state-changing side effects — reads only.
+- No task, ledger event, persisted artifact, file edit, or state-changing side
+  effect — reads only.
 - Every claim in the report is backed by evidence you actually observed,
   or labeled as unverified with the blocker named.
+- Opinions, future behavior, and hypothetical implementation approaches belong
+  in Brainstorming, not Investigation.
 
 ## Process
 
@@ -29,5 +32,8 @@ it.
    you could not test, report as an explicitly unverified hypothesis with
    the blocker that prevented the test.
 3. **Deliver the report**: the diagnosis (or ranked hypotheses) with its
-   evidence, the blockers, and the narrowest next step a fixing session
-   should take.
+   evidence, the blockers, and the narrowest useful next step.
+4. **Hand off only when the prompt needs design.** If unknown current facts
+   materially affect requested future behavior, finish the factual diagnosis
+   and then invoke `stdd-brainstorming`. Merely reading docs or code during
+   Brainstorming does not require a separate Investigation.

package/runtime/playbooks/planning.md

@@ -1,11 +1,15 @@
 ---
 name: stdd-planning
 description: Turn an agreed behavior contract into an executable, verifiable sequence of work
-when: The behavior contract is agreed (docs edit drafted or committed) and the change is large enough to need ordered steps — before the first implementation edit, to fix the execution mode and delivery boundary.
+when: The behavior contract is agreed (docs edit drafted or committed) and the change is more than one slice — a second independent outcome, an ordering dependency between parts, work to hand to another session, or an unresolved design decision — before the first implementation edit, to fix the execution mode and delivery boundary.
 ---
 
 # Planning
 
+A single-slice change does not come here: it goes straight to
+`stdd-implement`. Planning starts when a second slice appears, which is
+usually mid-work rather than at classification time.
+
 A plan is a disposable working artifact: it guides one execution and is thrown
 away. It is never committed as a file — its home is the PR description (for
 the durable summary) and `.stdd/plan.md` (for the working copy: per checkout,

package/runtime/playbooks/start-change.md

@@ -1,27 +1,24 @@
 ---
 name: stdd-start-change
-description: Classify a request, open durable task state only for changes, and route to the smallest applicable workflow
-when: A new implementation, fix, refactor, investigation, or repository change is beginning.
+description: Open durable task state and route work after explicit intent to persist or modify the repository
+when: The user explicitly wants a persisted work artifact or repository change.
 ---
 
 # Start change
 
-Classify the request before writing task state:
-
-- read-only question or diagnosis → invoke `stdd-investigation`; do not start a
-  task or write the ledger;
-- uncertain behavior or scope → invoke `stdd-brainstorming`;
-- agreed multi-step behavior → invoke `stdd-planning`;
-- known defect without a diagnosis → invoke `stdd-debugging`;
-- small agreed change → invoke `stdd-implement` directly.
+Start Change is the action boundary. Invoke it only after explicit intent to
+persist a work artifact or modify the repository. Read-only factual diagnosis
+routes directly to `stdd-investigation`; opinions, future behavior, and
+hypothetical implementation approaches route directly to `stdd-brainstorming`.
+Neither needs a task. A hypothetical plan shown only in chat remains
+Brainstorming.
 
 Run `stdd policy show` before asking anything: it may already answer which
 agent owns this area, which standing permission covers the work, and what this
 repository treats as routine rather than a decision. Read it through the
 command, never as raw markdown — the command is where the rules are applied.
 
-For every route that may change the repository, open one task boundary before
-carrying state across prompts:
+Open one task boundary before carrying action state across prompts:
 
 ```bash
 stdd task start "<short change name>"
@@ -31,7 +28,24 @@ stdd status --local
 If another task is active, do not reset it silently. Finish it, continue it,
 or ask the user which task owns the checkout.
 
-For a change, read `.stdd/method.md` and the canonical docs governing the
-touched behavior. The classification is a routing decision, not ceremony:
-skip workflows that do not apply, but never skip a mechanical contract that
-does.
+Then route. The default is one slice: invoke `stdd-implement` directly. A
+change is one slice when, at the moment of deciding, it has one agreed
+observable outcome, one coherent implementation boundary, one acceptance check,
+and no known dependency on another independently verifiable change.
+
+Escalate from that default only on a named trigger:
+
+- a second independent outcome or an ordering dependency between parts →
+  invoke `stdd-planning`;
+- work to hand to another session → invoke `stdd-planning`, then
+  `stdd-delegate-slice`;
+- a design decision nobody has made yet → invoke `stdd-brainstorming` within
+  the active change boundary;
+- a known defect without a diagnosis → invoke `stdd-debugging`.
+
+Any of them may appear mid-work. Escalating then is the normal case, not a
+failed classification.
+
+Read `.stdd/method.md` and the canonical docs governing the touched behavior.
+The classification is a routing decision, not ceremony: skip workflows that do
+not apply, but never skip a mechanical contract that does.

package/runtime/sdk/adapters.mjs

@@ -3,9 +3,6 @@ import { assertPrintableSingleLine } from "./text.mjs";
 
 const SEMVER_PATTERN =
 	/^(?:0|[1-9]\d*)\.(?:0|[1-9]\d*)\.(?:0|[1-9]\d*)(?:-([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?(?:\+[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*)?$/u;
-const CI_STAMP_PLACEHOLDER = "__STAMP__";
-const CI_VERSION_PLACEHOLDER = "__VERSION__";
-const CI_PLACEHOLDER_PATTERN = /__[A-Z][A-Z0-9_]*__/u;
 export const CROSS_CLI_REVIEW_VIA_TOKEN = "{{STDD_CROSS_CLI_REVIEW_VIA}}";
 const CROSS_CLI_REVIEW_VIAS = new Set(["claude", "codex"]);
 
@@ -17,6 +14,8 @@ const deepFreeze = (value) => {
 };
 
 export const MANDATORY_ROUTING_SKILLS = deepFreeze([
+	"stdd-investigation",
+	"stdd-brainstorming",
 	"stdd-start-change",
 	"stdd-implement",
 	"stdd-finish-change",
@@ -90,23 +89,6 @@ export function defineAgentAdapter(adapter) {
 	return deepFreeze(copy);
 }
 
-export function defineCiAdapter(adapter) {
-	const id = assertSkillName(adapter?.id, "CI adapter id");
-	const outputIsNull = adapter?.outputFile === null;
-	const templateIsNull = adapter?.templateFile === null;
-	if (outputIsNull !== templateIsNull) {
-		throw new TypeError("CI adapter outputFile and templateFile must both be null or both be paths");
-	}
-	const copy = {
-		id,
-		outputFile: outputIsNull ? null : requireRepoPath(adapter?.outputFile, "CI adapter outputFile"),
-		templateFile: templateIsNull
-			? null
-			: requireRepoPath(adapter?.templateFile, "CI adapter templateFile"),
-	};
-	return deepFreeze(copy);
-}
-
 export const AGENT_ADAPTERS = deepFreeze({
 	claude: defineAgentAdapter({
 		id: "claude",
@@ -137,24 +119,6 @@ export const AGENT_ADAPTERS = deepFreeze({
 	}),
 });
 
-export const CI_ADAPTERS = deepFreeze({
-	github: defineCiAdapter({
-		id: "github",
-		outputFile: ".github/workflows/stdd.yml",
-		templateFile: "github-stdd.yml",
-	}),
-	gitlab: defineCiAdapter({
-		id: "gitlab",
-		outputFile: ".gitlab/stdd.gitlab-ci.yml",
-		templateFile: "gitlab-stdd.yml",
-	}),
-	generic: defineCiAdapter({
-		id: "generic",
-		outputFile: null,
-		templateFile: null,
-	}),
-});
-
 export function getAgentAdapter(id) {
 	if (!Object.hasOwn(AGENT_ADAPTERS, id)) {
 		throw new Error(`unknown agent adapter ${JSON.stringify(id)}`);
@@ -162,13 +126,6 @@ export function getAgentAdapter(id) {
 	return AGENT_ADAPTERS[id];
 }
 
-export function getCiAdapter(id) {
-	if (!Object.hasOwn(CI_ADAPTERS, id)) {
-		throw new Error(`unknown CI adapter ${JSON.stringify(id)}`);
-	}
-	return CI_ADAPTERS[id];
-}
-
 function resolveAgentAdapter(adapter) {
 	return typeof adapter === "string" ? getAgentAdapter(adapter) : defineAgentAdapter(adapter);
 }
@@ -212,16 +169,27 @@ export function renderAgentInstructions({
 		throw new TypeError("agent instructions projectLogEnabled must be a boolean");
 	}
 	const invoke = (name) => `\`${adapter.explicitPrefix}${name}\``;
-	const [startChange, implement, finishChange] = MANDATORY_ROUTING_SKILLS;
+	const [investigation, brainstorming, startChange, implement, finishChange] = MANDATORY_ROUTING_SKILLS;
 	return [
 		`<!-- ${safeStamp} -->`,
 		"",
 		"## STDD",
 		"",
-		"This repository follows `.stdd/method.md`. Before any repository change",
-		"(behavior, implementation-only work, fixes, refactors, or investigation),",
-		`invoke ${invoke(startChange)}; use ${invoke(implement)} for`,
-		`the docs/red/green/verify slice and ${invoke(finishChange)} to close it.`,
+		"This repository follows `.stdd/method.md`. Route read-only current-state",
+		`factual or diagnostic questions directly to Investigation with ${invoke(investigation)}.`,
+		"Route opinions, future behavior, and hypothetical implementation approaches",
+		`directly to Brainstorming with ${invoke(brainstorming)}.`,
+		"",
+		"Use Investigation → Brainstorming only when unknown current facts materially affect future design.",
+		"Reading docs or code during Brainstorming does not by itself require Investigation.",
+		"",
+		"Start Change is the action boundary. Invoke it only after explicit intent to",
+		`persist a work artifact or modify the repository, using ${invoke(startChange)}.`,
+		"A hypothetical plan shown only in chat remains Brainstorming.",
+		"",
+		"Before any repository change (behavior, implementation-only work, fixes, or",
+		`refactors), invoke ${invoke(startChange)}; use ${invoke(implement)} for the`,
+		`docs/red/green/verify slice and ${invoke(finishChange)} to close it.`,
 		"",
 		...(projectLogEnabled
 			? [
@@ -261,19 +229,3 @@ export function renderAgentInstructions({
 		"",
 	].join("\n");
 }
-
-export function renderCiTemplate(template, { stamp, version }) {
-	const safeTemplate = requireString(template, "CI template");
-	const safeStamp = assertPrintableSingleLine(stamp, "CI stamp");
-	const safeVersion = assertSemanticVersion(version, "CI version");
-	if (!safeTemplate.includes(CI_STAMP_PLACEHOLDER) || !safeTemplate.includes(CI_VERSION_PLACEHOLDER)) {
-		throw new TypeError("CI template must contain __STAMP__ and __VERSION__ placeholders");
-	}
-	const rendered = safeTemplate.replace(/__STAMP__|__VERSION__/gu, (placeholder) =>
-		placeholder === CI_STAMP_PLACEHOLDER ? safeStamp : safeVersion,
-	);
-	if (CI_PLACEHOLDER_PATTERN.test(rendered)) {
-		throw new TypeError("CI template contains an unresolved placeholder");
-	}
-	return rendered;
-}

package/runtime/sdk/index.d.ts

@@ -49,17 +49,9 @@ export interface AgentAdapter {
 	readonly hooksFile: string;
 	readonly crossCliReviewVia?: "codex" | "claude" | null;
 }
-export interface CiAdapter {
-	readonly id: string;
-	readonly outputFile: string | null;
-	readonly templateFile: string | null;
-}
 export const AGENT_ADAPTERS: DeepReadonly<Record<"claude" | "codex" | "pi", AgentAdapter>>;
-export const CI_ADAPTERS: DeepReadonly<Record<"github" | "gitlab" | "generic", CiAdapter>>;
 export function defineAgentAdapter(adapter: AgentAdapter): DeepReadonly<AgentAdapter>;
-export function defineCiAdapter(adapter: CiAdapter): DeepReadonly<CiAdapter>;
 export function getAgentAdapter(id: string): AgentAdapter;
-export function getCiAdapter(id: string): CiAdapter;
 export function renderAgentSkill(input: {
 	adapter?: string | AgentAdapter;
 	name: string;
@@ -75,7 +67,6 @@ export function renderAgentInstructions(input: {
 	crossCli: boolean;
 	projectLogEnabled?: boolean;
 }): string;
-export function renderCiTemplate(template: string, input: { stamp: string; version: string }): string;
 export function assertSkillName(name: string, label?: string): string;
 export function isPrintableSingleLine(value: unknown): value is string;
 export function assertPrintableSingleLine(value: unknown, label?: string): string;

package/runtime/sdk/index.mjs

@@ -12,14 +12,10 @@ export {
 } from "../cli/lib.mjs";
 export {
 	AGENT_ADAPTERS,
-	CI_ADAPTERS,
 	defineAgentAdapter,
-	defineCiAdapter,
 	getAgentAdapter,
-	getCiAdapter,
 	renderAgentInstructions,
 	renderAgentSkill,
-	renderCiTemplate,
 } from "./adapters.mjs";
 export { assertSkillName, resolveRepoPath, resolveWritableRepoPath } from "./path.mjs";
 export { assertPrintableSingleLine, isPrintableSingleLine } from "./text.mjs";