@selesai/code 0.13.11 → 0.13.13

package/dist/extensions/pi-subagents/package.json

@@ -1,109 +0,0 @@
-{
-  "name": "pi-subagents",
-  "version": "0.61.0",
-  "description": "Selesai extension for single-agent delegation and scripted multi-agent workflows",
-  "author": "Nico Bailon",
-  "license": "MIT",
-  "type": "module",
-  "exports": {
-    ".": "./index.ts",
-    "./background-work": "./src/api/background-work.ts",
-    "./external-job-provider": "./src/api/external-job-provider.ts",
-    "./external-runs": "./src/api/external-runs.ts",
-    "./agents": "./src/api/agents.ts",
-    "./delegation": "./src/api/delegation.ts",
-    "./capability-ceiling": "./src/api/capability-ceiling.ts",
-    "./preflight": "./src/api/preflight.ts",
-    "./control-channel": "./src/api/control-channel.ts",
-    "./intercom-bridge": "./src/api/intercom-bridge.ts",
-    "./pi-args": "./src/api/pi-args.ts",
-    "./shared-types": "./src/api/shared-types.ts",
-    "./project-panes": "./src/api/project-panes.ts"
-  },
-  "repository": {
-    "type": "git",
-    "url": "git+https://github.com/nicobailon/pi-subagents.git"
-  },
-  "homepage": "https://github.com/nicobailon/pi-subagents#readme",
-  "bugs": {
-    "url": "https://github.com/nicobailon/pi-subagents/issues"
-  },
-  "keywords": [
-    "pi-package",
-    "pi",
-    "pi-coding-agent",
-    "subagents",
-    "ai",
-    "agents",
-    "cli"
-  ],
-  "bin": {
-    "pi-subagents": "install.mjs"
-  },
-  "files": [
-    "index.ts",
-    "src/**/*.ts",
-    "*.mjs",
-    "agents/",
-    "skills/**/*",
-    "prompts/**/*",
-    "docs/**/*",
-    "README.md",
-    "CHANGELOG.md"
-  ],
-  "scripts": {
-    "typecheck": "tsc --noEmit",
-    "test": "npm run test:unit",
-    "test:unit": "node --experimental-strip-types --import ./test/support/isolated-temp-root.mjs --test test/unit/*.test.ts",
-    "test:integration": "node --experimental-strip-types --import ./test/support/register-loader.mjs --test test/integration/*.test.ts",
-    "test:e2e": "node --experimental-strip-types --import ./test/support/register-loader.mjs --test test/e2e/*.test.ts",
-    "test:all": "npm run test:unit && npm run test:integration && npm run test:e2e"
-  },
-  "pi": {
-    "extensions": [
-      "./index.ts"
-    ],
-    "skills": [
-      "./skills"
-    ],
-    "prompts": [
-      "./prompts"
-    ]
-  },
-  "peerDependencies": {
-    "@earendil-works/pi-agent-core": "*",
-    "@earendil-works/pi-ai": ">=0.80.0",
-    "@selesai/code": "*",
-    "@earendil-works/pi-tui": "*"
-  },
-  "peerDependenciesMeta": {
-    "@earendil-works/pi-agent-core": {
-      "optional": true
-    },
-    "@earendil-works/pi-ai": {
-      "optional": true
-    },
-    "@selesai/code": {
-      "optional": true
-    },
-    "@earendil-works/pi-tui": {
-      "optional": true
-    }
-  },
-  "dependencies": {
-    "acorn": "8.18.0",
-    "jiti": "2.7.0",
-    "typebox": "1.1.38",
-    "yaml": "2.8.3"
-  },
-  "devDependencies": {
-    "@earendil-works/pi-agent-core": "0.81.0",
-    "@earendil-works/pi-ai": "0.81.0",
-    "@earendil-works/pi-tui": "0.81.0",
-    "@oxlint/plugins": "1.80.0",
-    "@types/node": "24.13.3",
-    "oxlint": "1.80.0",
-    "typescript": "5.9.3",
-    "@selesai/code": "file:./test/fixtures/pi-coding-agent-shim"
-  }
-}

package/dist/extensions/pi-subagents/prompts/council.md

@@ -1,60 +0,0 @@
----
-description: Run a bounded supervisor-mediated council of advisors and write a decision memo
-argument-hint: "<question> [--advisors name,name] [--max-passes 2|3] [--scope ...] [--non-goals ...]"
----
-
-Run a bounded, supervisor-mediated council on this question. You, the parent
-session, are the supervisor. You select the roster, curate cross-advisor packets,
-decide which feedback is valid, and write the final memo. Advisors do not talk
-directly or see peer transcripts by default. This is not free-form agent chat.
-
-Before you orchestrate, read `skills/council-mode/SKILL.md` and
-`skills/pi-subagents/references/execution-controls.md`.
-
-Parse the invocation yourself. The flags below are conventions, not runtime
-options. Record a brief with the question, scope, non-goals, evidence targets,
-roster, known advisor context modes, and pass cap. Default `--max-passes` to 2.
-Clamp it to 2 or 3. If the question is trivial or settled, answer directly instead
-of convening a council.
-
-## Roster
-
-- If `--advisors` is given, use exactly those agent names. Fail clearly on an
-  unknown agent. Do not require or invent per-advisor role labels.
-- Otherwise list agents with `subagent({ action: "list" })`, then prefer 2–3
-  executable names that start with `council-`.
-- If fewer than two profiles are available, fill the roster with `oracle`, then
-  `reviewer`, until it has two advisors. Launch fallback `oracle` with
-  `context: "fork"` so global defaults cannot remove its parent-chat context.
-  Let `reviewer` use its normal profile context. Note the fallback and known
-  context modes in the memo.
-- Use the normal single-oracle loop only when a requested roster or unavailable
-  builtins leaves fewer than two advisors. Label the memo as degraded mode.
-
-Profiles provide the model, tools, context, and advisor stance. The council
-question and scope provide the decision frame. If the user wants a specific lens,
-they should put it in the question, scope, or profile definition. Keep the roster
-at 2–3 and never exceed 4.
-
-Package advisors such as Surf's `gpt-pro` are valid only when the package Pi
-extension is installed and its external-job provider is registered. For Surf,
-that means the `surf-cli` Pi extension has loaded and `surf-oracle` appears in
-`subagent({ action: "list" })` or the advisor is explicitly requested in
-`--advisors` after that install. Treat them as external-runner advisors: omit
-child `async` for normal attached council results, do not pass `outputSchema`,
-include any needed evidence in the prompt, and use the fresh fallback cross-exam
-path if the run is not resumable.
-
-## Run the protocol
-
-Use the canonical workflow, structured advisor contracts, aggregate pass receipts,
-and memo requirements in `skills/council-mode/SKILL.md`. Keep the parent as the
-only synthesizer and decision maker. Do not introduce a chair advisor, peer chat,
-or transcript sharing.
-
-Use its required boundary checkpoints, yield for each async workflow without
-polling, and write its required final memo.
-
-Question and options from the slash command invocation:
-
-$@

package/dist/extensions/pi-subagents/prompts/gather-context-and-clarify.md

@@ -1,13 +0,0 @@
----
-description: Use subagents to gather context, then ask clarifying questions
----
-
-Based on our discussion and my intent, launch focused context-gathering subagents before planning or implementing.
-
-Use `scout` to inspect the relevant local files, existing patterns, constraints, tests, and likely integration points. Use `researcher` when external docs, recent sources, ecosystem context, or primary evidence would improve the answer.
-
-Give each subagent a specific meta prompt. Ask them to return concise findings plus the remaining clarification questions that matter for implementation confidence.
-
-After they return, synthesize what we know and use the `interview` tool to ask me the unresolved questions needed to reach a shared understanding.
-
-$@

package/dist/extensions/pi-subagents/prompts/parallel-cleanup.md

@@ -1,59 +0,0 @@
----
-description: Parallel cleanup review
----
-
-Run a fresh-context parallel cleanup review of the current work.
-
-Use the `subagent` tool. First inspect available agents/skills if needed, then launch two reviewer subagents in parallel with `context: "fresh"`. Do not use forked context unless I explicitly ask for it. Reviewers must inspect the repository, relevant instructions, and current diff directly from files and commands. They must not rely on the main conversation history.
-
-Do not write reviewer output files into the repository unless I explicitly ask for artifacts. Prefer `output: false` for each reviewer task.
-
-Reviewer 1: deslop pass.
-
-If the `deslop` skill is available, pass it to this reviewer. If not, inline the guidance below. Ask this reviewer to look for AI-slop patterns in the changed scope:
-- comments that restate code, placeholder text, stale rationale, or debug leftovers;
-- defensive checks that hide useful errors, return vague defaults, or validate trusted internal data after a real boundary was already crossed;
-- type escapes, broad casts, duplicated type definitions, or object-bag typing where a local source-of-truth type exists;
-- style drift from nearby non-slop code and project instructions;
-- generated-sounding docs, changelog text, UI copy, status text, or test names;
-- pass-through wrappers, dead helpers, duplicate helper signatures, duplicated test harness setup, or abstractions that do not enforce an invariant;
-- UI or CLI copy that is noisy, vague, brittle, or makes the user do extra interpretation.
-
-Tell this reviewer to treat tool output and slop-scan-style findings as leads, not verdicts. It should flag only concrete issues in the requested scope with evidence, severity, file/line references, and the smallest safe fix.
-
-Reviewer 2: verbosity pass.
-
-If the `verbosity-cleaner` skill is available, pass it to this reviewer. If not, inline the guidance below. Ask this reviewer to look for needless verbosity in code, tests, docs, status text, grouped messages, receipts, and changelog wording:
-- single-use helpers that merely paraphrase an expression;
-- temporary variables that only name obvious expressions;
-- nested returns or branches that can become direct returns without hiding intent;
-- multi-line cleanup scaffolding that can use a local direct pattern while preserving cleanup semantics;
-- repeated boilerplate that can use an existing local fixture or a small local helper;
-- tests that restate formatter details already covered at a cheaper layer;
-- regression tests where one focused assertion would cover the bug but wrapper/API-adjacent tests only repeat the same claim;
-- prose that says the same thing twice, sounds generic, or buries the important rule.
-
-Tell this reviewer that shorter is only better when it is clearer and preserves behavior, error signals, cleanup semantics, useful invariants, and local style.
-
-Both reviewers are review-only. They must not edit files unless I explicitly ask for a writer pass. Their response should be review feedback, not a context summary. Ask them to return concise, evidence-backed findings with file/line references and suggested fixes.
-
-While reviewers run, do your own narrow inspection if useful. After they return, synthesize the feedback into:
-- fixes worth doing now;
-- optional improvements;
-- feedback to ignore or defer, with a short reason.
-
-Do not blindly apply every reviewer suggestion.
-
-Autofix mode: if the invocation contains the exact word `autofix`, treat it as workflow control, not cleanup scope. Remove it before deciding the cleanup target. After synthesis, apply only fixes worth doing now, validate, and summarize. Do not apply optional improvements unless explicitly requested. If there are no fixes worth doing now, do not edit.
-
-Without autofix mode, ask before applying fixes unless I already told you to address review feedback. When you ask, end with a compact numbered menu so I can respond with a number. Use wording suited to the findings, but include these choices when applicable:
-
-```text
-Reply with [1], [2], or further instructions:
-[1] Apply only the fixes worth doing now.
-[2] Apply the fixes worth doing now plus optional improvements.
-```
-
-Additional scope or focus from the slash command invocation:
-
-$@

package/dist/extensions/pi-subagents/prompts/parallel-research.md

@@ -1,50 +0,0 @@
----
-description: Parallel subagents research
----
-
-Launch parallel research subagents to build a grounded answer to the current question or decision.
-
-Use fresh context, not forked context, unless I explicitly ask for forked context. Researchers and scouts should inspect sources directly instead of relying on the main conversation history.
-
-Use a combination of `researcher` and `scout` subagents:
-- Use `researcher` for web, docs, standards, ecosystem, recent changes, benchmarks, and primary-source evidence.
-- Use `scout` for local codebase context, existing implementation patterns, repo constraints, and files that would be affected.
-
-Give each subagent a distinct angle. Unless I specify angles, use these three:
-
-1. External evidence
-   Use `researcher` to find current, authoritative sources: official docs, specs, release notes, benchmarks, issue threads, or primary explanations.
-
-2. Local code context
-   Use `scout` to inspect the repository for relevant files, existing patterns, constraints, tests, and likely integration points.
-
-3. Practical tradeoffs
-   Use `researcher` or `scout`, whichever fits the question, to compare options, risks, edge cases, maintenance cost, and what would be easiest to validate.
-
-Adapt the angles when the question calls for it:
-- Library/API questions: include official docs and recent examples.
-- Architecture decisions: include local module boundaries, dependency direction, and migration cost.
-- Debugging questions: include likely failure modes, local call paths, and exact error evidence.
-- UI/product questions: include user flow, accessibility, design precedent, and implementation constraints.
-- Time-sensitive topics: include a recent-developments angle and prefer 2026/2025 sources.
-
-Prefer two or three strong subagents over many vague ones. The parent agent should frame the question and assign angles; the child agents should research or scout, not invent broad plans.
-
-Ask each subagent to return concise findings with evidence:
-- file paths and line ranges for local findings
-- source links for external findings
-- confidence level and gaps
-- recommended next step or decision implication
-
-Do not ask subagents to edit files. This is a research pass only unless I explicitly ask for implementation.
-
-After the subagents return, synthesize the answer into:
-- what we know
-- what the local codebase implies
-- tradeoffs and risks
-- gaps or assumptions
-- the recommended next move
-
-If findings disagree, call out the disagreement instead of smoothing it over.
-
-$@

package/dist/extensions/pi-subagents/prompts/parallel-review.md

@@ -1,58 +0,0 @@
----
-description: Parallel subagents review
----
-
-Launch parallel reviewers for an adversarial review of the current work.
-
-Use fresh context, not forked context, unless I explicitly ask for forked context. Reviewers should inspect the repository, relevant instructions, and current diff directly from files and commands. Do not rely on the main conversation history.
-
-Give each reviewer a distinct angle. Generate the angles dynamically from the user's intent, the plan, the implemented code, and the current diff. If I specify angles, use mine. Otherwise, choose the highest-value review angles for this specific work.
-
-These are examples, not fixed defaults:
-
-1. Correctness and regressions
-   Check whether the change satisfies the request, preserves existing behavior, handles edge cases, and avoids hidden runtime failures.
-
-2. Tests and validation
-   Check whether tests or validation were added at the right layer, whether assertions are meaningful, and whether the chosen verification commands are enough.
-
-3. Simplicity and maintainability
-   Check for unnecessary complexity, duplicate structure, single-use wrappers, brittle abstractions, confusing names, verbosity, and cleanup that is clearly worth doing.
-
-Choose or adapt angles when the work calls for it:
-- TypeScript-heavy changes: include type safety, source-of-truth types, casts, and error-boundary discipline.
-- UI-heavy changes: include UX, accessibility, copy, and visual quality.
-- Security-sensitive changes: include unsafe input/output handling, auth boundaries, privacy, and data exposure.
-- Docs-heavy changes: include clarity, accuracy, completeness, reader flow, and non-robotic prose.
-- Large multi-file changes: consider a fourth reviewer for structural friction, module boundaries, and testability.
-
-Prefer three strong reviewers over many vague reviewers.
-
-Give every reviewer a specific task prompt naming its angle. Ask reviewers to return concise, evidence-backed findings with file/line references and suggested fixes. Filter on evidence, not severity: a finding must be concrete, current, caused or made reachable by the target diff, and supported by source proof, a test or repro, or a contract contradiction. Label findings P0/P1/P2. P0 blocks merge. P1 should be fixed before release. P2 is report-only. End each review with `Merge verdict: BLOCK`, `Merge verdict: OK`, or `Merge verdict: OK with notes`. If nothing qualifies, ask the reviewer to say exactly `No issues found.` The response should be review feedback, not a context summary. Reviewers must not edit files unless I explicitly ask for a writer pass.
-
-Do not default first-pass reviews to `blockers only`. That phrase is valid only for final pre-merge re-checks after P1/P2 findings are already inventoried, or for explicit emergency hotfix lanes where non-blocking findings are intentionally deferred.
-
-For a targeted follow-up review, ask only whether the named finding was resolved, whether the fix introduced a new defect in the fix blast radius, and whether prior P1/P2 notes still stand. For bot or PR-comment triage, classify each comment as VALID, STALE, INVALID, or OUT-OF-POLICY against current HEAD, then assign P0/P1/P2 only to VALID comments.
-
-While reviewers run, do your own narrow inspection if useful. After they return, synthesize the feedback into:
-- fixes worth doing now
-- optional improvements
-- feedback to ignore or defer, with a short reason
-
-Do not blindly apply every reviewer suggestion.
-
-Autofix mode: if the invocation contains the exact word `autofix`, treat it as workflow control, not review scope. Remove it before deciding the review target. After synthesis, apply only fixes worth doing now, validate, and summarize. Do not apply optional improvements unless explicitly requested. If there are no fixes worth doing now, do not edit.
-
-Without autofix mode, ask before applying fixes unless I already told you to address review feedback. When you ask, end with a compact numbered menu so I can respond with a number. Use wording suited to the findings, but include these choices when applicable:
-
-```text
-Reply with [1], [2], or further instructions:
-[1] Apply only the fixes worth doing now.
-[2] Apply the fixes worth doing now plus optional improvements.
-```
-
-Additional review target or focus from the slash command invocation:
-
-$@
-
-If the invocation provides a URL, issue link, file path, plan path, or freeform focus, treat it as the primary review scope. Read or fetch that target before assigning reviewer angles, and pass the target explicitly into each reviewer task.

package/dist/extensions/pi-subagents/prompts/review-loop.md

@@ -1,47 +0,0 @@
----
-description: Review/fix loop until clean
----
-
-Run a parent-orchestrated review loop for the requested work.
-
-Use the `subagent` tool. Keep the parent session as the loop controller and final decision-maker. Child subagents must receive concrete role-specific tasks; they must not run subagents or manage the loop themselves unless the parent intentionally selected an explicit fanout agent whose builtin `tools` includes `subagent` for that assigned fanout.
-
-Default to a maximum of 3 review rounds unless I specify a different cap. Count a review round each time fresh-context reviewers inspect the current diff after a worker pass. Stop early when reviewers find no P0 findings, no P1 fixes worth doing now, and no approved P2 notes that should be handled in this loop.
-
-If the invocation includes an implementation request, first launch one async `worker` to implement the approved scope. If the current diff is already the target, start with review. The sequence can be launched up front with `workflowScript` when it is already clear, or continued as follow-up single-agent runs after each async completion. For an initial workflowScript, pass `async: true` so the main chat is unblocked; do not set `clarify: true` unless I explicitly want the foreground clarify UI. Use only one writer against the active worktree at a time unless I explicitly ask for isolated worktrees.
-
-As a conservative orchestration policy, do not set a hard `toolBudget` or tight `usageBudget` on implementation or fix workers. A default tool budget blocks read/search tools rather than mutation tools, and reported usage has no reservation model, so count or usage limits still do not measure delivery safety. Give each writer a narrow delivery slice and an outer elapsed deadline with enough margin. Before that deadline, request a checkpoint after the current tool returns with changed files, build/test state, remaining work, and commit or PR state. An elapsed timeout is not a mutation-safe boundary and must not be the checkpoint trigger.
-
-For each review round, launch fresh-context `reviewer` agents in parallel. Reviewers must inspect the repository, relevant instructions, and current diff directly from files and commands. They must not rely on the main conversation history and must not edit files.
-
-Tell reviewers to filter on evidence, not severity. They should report only concrete current issues caused or made reachable by the target diff, with source proof, a test or repro, or a contract contradiction. Ask them to label findings P0/P1/P2 and end with `Merge verdict: BLOCK`, `Merge verdict: OK`, or `Merge verdict: OK with notes`. P0 blocks merge. P1 should be fixed before release. P2 is report-only. Use `blockers only` only for final pre-merge re-checks after P1/P2 findings are already captured, or for explicit emergency hotfix lanes.
-
-Choose review angles from the actual change. Common angles are correctness/regressions, tests/validation, and simplicity/maintainability. Add security, performance, docs/API contracts, or user-flow validation when the work calls for it. Prefer three strong reviewers over many vague reviewers.
-
-After reviewers return, synthesize their feedback into:
-- P0 blockers or scope/product/architecture decisions that need user approval;
-- P1 fixes worth doing now;
-- P2 report-only notes or optional improvements;
-- feedback to ignore or defer, with a short reason.
-
-Do not blindly apply every reviewer suggestion. If reviewers surface an unapproved product, scope, or architecture decision, pause and ask me before launching a fix worker.
-
-When an async implementation worker completes, treat its handoff as the transition into review, not as final completion, unless I explicitly asked for worker-only work, review-only output, or to stop after implementation.
-
-When there are fixes worth doing now and the workflow is implementation-authorized, launch one async forked `worker` without hard tool-call caps to apply only those synthesized fixes. Ask it to preserve the approved scope, run focused validation, and report changed files, commands run with exit codes, validation evidence, surprises, and anything left undone.
-
-After a fix worker returns, run another review round only when it made material changes or addressed non-trivial findings. Do not keep looping for optional polish, speculative improvements, or findings already deferred by the parent.
-
-For a targeted follow-up review, ask only three questions: whether the named finding was resolved, whether the fix introduced a new concrete defect in the fix blast radius, and whether prior P1/P2 notes still stand. End with a fix verdict and the merge verdict.
-
-Stop and summarize when one of these is true:
-- reviewers find no P0 blockers or P1 fixes worth doing now;
-- remaining feedback is optional, speculative, or intentionally deferred;
-- reviewers surface an unapproved decision that needs me;
-- the max review-round cap is reached.
-
-On completion, inspect the final diff yourself, run or confirm focused validation where appropriate, and summarize the loop: rounds run, fixes applied, validation, remaining deferred items, and why the loop stopped.
-
-Additional target, implementation request, max-iteration cap, or review focus from the slash command invocation:
-
-$@

package/dist/extensions/pi-subagents/skills/council-mode/SKILL.md

@@ -1,59 +0,0 @@
----
-name: council-mode
-description: Run a bounded supervisor-mediated advisor council. Use when the user asks for council mode, asks to convene advisors, debate a decision, cross-examine recommendations, or run /council.
----
-
-# Council Mode
-
-Council mode is parent-supervised advice for a material decision with real tradeoffs. It is not free-form agent chat, implementation work, a transcript dump, mutation authority, or a council UI.
-
-The parent selects the roster, relays only curated claims, decides validity, and writes the memo. Advisors stay read-only and do not see peer transcripts by default.
-
-Before launch, read:
-
-- `skills/pi-subagents/references/execution-controls.md`
-- `skills/council-mode/references/pass-contracts.md`
-
-## Roster
-
-Run `subagent({ action: "list" })`, then choose 2-3 executable advisor names that start with `council-`. The prefix is convention only. Never use more than four advisors.
-
-If fewer than two council profiles are available, fill with `oracle`, then `reviewer`. Launch fallback `oracle` with `context: "fork"`; let fallback `reviewer` use its normal profile context. Note fallbacks and known context modes in the memo. If fewer than two advisors remain, use the normal one-oracle consultation loop and label it degraded mode.
-
-`council-*` profiles live in user or project agent directories, not this package. A profile defines model, tools, context, output defaults, and persistent stance. Keep advisors read-only, disable inherited skills unless needed, and put stance in the profile body instead of inventing per-run role labels.
-
-External-job/package advisors may join only when their provider is registered. Treat them as ordinary advisor names in `runs.all`, but honor their runner limits: they may lack repo tools, structured output, or resumability. Include evidence they cannot read, request JSON text instead of `outputSchema`, and use a fresh-context fallback when they cannot resume for cross-exam.
-
-## Passes
-
-Pass 1 is independent reports. Pass 2 is one cross-exam. Run Pass 3 only when `--max-passes 3` was requested and a material dispute can still be settled by evidence. Never run an unbounded loop.
-
-## Protocol
-
-1. Write the council brief: question, scope, non-goals, evidence targets, roster, known advisor context modes, and pass cap.
-2. Tell the user the roster, context modes, and pass cap.
-3. Launch one async `workflowScript` with `runs.all` for Pass 1. Use stable keys, `phase: "Council pass 1"`, concise labels, and `output: false` unless separate artifacts are useful. Set `context` only when the profile context is known or a fallback rule requires it.
-4. Return one aggregate Pass 1 receipt. On completion, tell the user completion count, agreement count, dispute count, and whether Pass 2 is needed.
-5. Synthesize the claim matrix in the parent: agreements, disputed claims, missing proof, owner decisions, and at most five material relay claims per advisor.
-6. For Pass 2, tell the user which claims are relayed and why they matter. Resume each advisor with a curated challenge packet. A resume needs a retained run id and task; it excludes `agent` and rejects `gate`. Record each new run id; Pass 3 resumes those latest ids with new stable keys.
-7. Stop at convergence, pass cap, failed fallback, or user interruption. The parent writes the final memo.
-
-If an advisor is not resumable, run the same profile fresh with its Pass 1 report and challenge packet. Label it a fresh-context fallback, not true cross-exam.
-
-Do not set `clarify`, `worktree`, `gate`, tool budgets, or tight usage budgets on advisors. Bound work through the roster, pass cap, and report length.
-
-## Memo
-
-Converged means no disputed claim remains that both affects the recommendation and can plausibly be settled by advisor evidence. Put unresolved disputes in owner decisions. Do not add a round for polish or symmetry.
-
-The memo states:
-
-- question and scope
-- recommendation and rationale
-- accepted and rejected feedback with reasons
-- owner decisions
-- evidence and run ids
-- confidence and what would change the decision
-- roster, passes, fallbacks, and known advisor context modes
-
-Identify advisors by profile name. State when fallback `oracle` was forked and context-aware. Escalate to a writer only after the memo and only when the user requests it.

package/dist/extensions/pi-subagents/skills/council-mode/references/pass-contracts.md

@@ -1,150 +0,0 @@
-# Council Mode Pass Contracts
-
-Load this before launching council advisors.
-
-## Pass 1 report
-
-Native Pi advisors should receive this `outputSchema`. External runners should receive the same shape as plain JSON text and no `outputSchema`.
-
-```js
-const pass1OutputSchema = {
-  type: "object",
-  required: [
-    "recommendation",
-    "evidence",
-    "assumptions",
-    "risks",
-    "confidence",
-    "challengeClaims",
-    "ownerDecisions",
-    "changeMyMind"
-  ],
-  properties: {
-    recommendation: { type: "string" },
-    evidence: {
-      type: "array",
-      items: {
-        type: "object",
-        required: ["claim", "sources"],
-        properties: {
-          claim: { type: "string" },
-          sources: { type: "array", items: { type: "string" } }
-        }
-      }
-    },
-    assumptions: {
-      type: "array",
-      items: {
-        type: "object",
-        required: ["assumption", "status"],
-        properties: {
-          assumption: { type: "string" },
-          status: { enum: ["verified", "unverified"] }
-        }
-      }
-    },
-    risks: { type: "array", items: { type: "string" } },
-    confidence: {
-      type: "object",
-      required: ["level", "reason"],
-      properties: {
-        level: { enum: ["high", "medium", "low"] },
-        reason: { type: "string" }
-      }
-    },
-    challengeClaims: { type: "array", items: { type: "string" }, maxItems: 3 },
-    ownerDecisions: { type: "array", items: { type: "string" } },
-    changeMyMind: { type: "array", items: { type: "string" } }
-  }
-};
-```
-
-Task text:
-
-- inspect supplied evidence directly
-- do not ask other advisors or read peer reports
-- stay read-only
-- do not spawn children
-- return only the structured report
-- keep the report under about 600 words
-
-For external runners, say: `Return only JSON matching this shape. Do not wrap it in Markdown.` Include any evidence they cannot read with tools.
-
-## Pass 1 aggregate receipt
-
-Return one aggregate receipt. Preserve result order or map it by stable key.
-
-```js
-return {
-  pass: 1,
-  advisors: results.map((result, index) => ({
-    key: result.key,
-    agent: result.agent,
-    requestedContext: roster[index].context ?? "runtime-default-unknown",
-    runId: result.runId,
-    report: result.structuredOutput ?? result.output
-  }))
-};
-```
-
-Do not replace `runtime-default-unknown` with a guessed context.
-
-## Pass 2 challenge
-
-A challenge packet contains only disputed claims, strong conflicting evidence, missing proof, owner decisions, and high-impact risks. Attribute peer content as "another advisor". Do not include full peer reports.
-
-Native Pi advisors receive `pass2OutputSchema`. External runners and fresh external fallbacks receive the same shape as JSON-only task text and no `outputSchema`.
-
-```js
-const pass2OutputSchema = {
-  type: "object",
-  required: ["responses", "recommendationChanged", "outOfScopeFindings"],
-  properties: {
-    responses: {
-      type: "array",
-      items: {
-        type: "object",
-        required: ["claimId", "disposition", "reason", "sources"],
-        properties: {
-          claimId: { type: "string" },
-          disposition: { enum: ["accept", "reject", "refine", "owner-decision"] },
-          reason: { type: "string" },
-          sources: { type: "array", items: { type: "string" } }
-        }
-      }
-    },
-    recommendationChanged: {
-      type: "object",
-      required: ["changed", "reason"],
-      properties: {
-        changed: { type: "boolean" },
-        reason: { type: "string" }
-      }
-    },
-    outOfScopeFindings: { type: "array", items: { type: "string" } }
-  }
-};
-```
-
-Use stable resume keys such as `cross-oracle`, `phase: "Council pass 2"`, concise labels, and `output: false` unless separate artifacts are useful. The aggregate Pass 2 receipt uses the Pass 1 row shape with the new `runId` and `structuredOutput ?? output`. Pass 3 resumes those latest ids with new stable keys.
-
-## Advisor profile template
-
-Create model-based advisors in the user or project agent directory, not in this package:
-
-```markdown
----
-name: council-sol
-description: Read-only fresh-context advisor for bounded council decisions
-tools: read, grep, find, ls
-model: provider/top-reasoning-model
-thinking: high
-systemPromptMode: replace
-inheritProjectContext: true
-inheritSkills: false
-defaultContext: fresh
-acceptanceRole: read-only
----
-
-Analyze the council question independently. Inspect evidence directly. Do not edit, run mutating commands, commit, push, contact peers, or spawn subagents. Return concise, cited advice using the report contract in the council task.
-```