@oh-my-pi/pi-coding-agent 15.10.10 → 15.10.11

package/src/modes/setup-wizard/scenes/sign-in.ts

@@ -68,7 +68,7 @@ export class SignInTab implements SetupTab {
 		this.#selector.handleInput(data);
 	}
 
-	render(width: number): string[] {
+	render(width: number): readonly string[] {
 		const lines: string[] = [];
 		if (this.#loggingInProvider) {
 			lines.push(theme.bold(`Signing in to ${this.#loggingInProvider}`));

package/src/modes/setup-wizard/scenes/theme.ts

@@ -117,7 +117,7 @@ class ThemeSceneController implements SetupSceneController {
 		this.#selectList.handleInput(data);
 	}
 
-	render(width: number): string[] {
+	render(width: number): readonly string[] {
 		const lines = [
 			theme.fg("muted", "Theme changes preview live. Nothing is saved until you press Enter."),
 			this.#mode === "all"

package/src/modes/setup-wizard/scenes/types.ts

@@ -31,7 +31,7 @@ export interface SetupTab {
 	 * login). The parent scene MUST NOT switch tabs or finish while modal.
 	 */
 	readonly modal: boolean;
-	render(width: number): string[];
+	render(width: number): readonly string[];
 	handleInput(data: string): void;
 	invalidate(): void;
 	/** Called when the tab becomes active (including initial mount). */

package/src/modes/setup-wizard/scenes/web-search.ts

@@ -63,7 +63,7 @@ export class WebSearchTab implements SetupTab {
 		this.#disposed = true;
 	}
 
-	render(width: number): string[] {
+	render(width: number): readonly string[] {
 		const lines = [
 			theme.fg("muted", "Choose the provider the web_search tool should prefer."),
 			"",

package/src/modes/setup-wizard/wizard-overlay.ts

@@ -116,7 +116,7 @@ export class SetupWizardComponent implements Component {
 		this.#activeScene?.handleInput?.(data);
 	}
 
-	render(width: number): string[] {
+	render(width: number): readonly string[] {
 		const safeWidth = Math.max(1, width);
 		const height = Math.max(1, this.ctx.ui.terminal.rows);
 		let lines: string[];

package/src/modes/types.ts

@@ -28,6 +28,7 @@ import type { HookInputComponent } from "./components/hook-input";
 import type { HookSelectorComponent, HookSelectorOptions } from "./components/hook-selector";
 import type { StatusLineComponent } from "./components/status-line";
 import type { ToolExecutionHandle } from "./components/tool-execution";
+import type { TranscriptContainer } from "./components/transcript-container";
 import type { LoopLimitRuntime } from "./loop-limit";
 import type { OAuthManualInputManager } from "./oauth-manual-input";
 import type { Theme } from "./theme/theme";
@@ -76,7 +77,7 @@ export type InteractiveSelectorDialogOptions = ExtensionUIDialogOptions & Pick<H
 export interface InteractiveModeContext {
 	// UI access
 	ui: TUI;
-	chatContainer: Container;
+	chatContainer: TranscriptContainer;
 	pendingMessagesContainer: Container;
 	statusContainer: Container;
 	todoContainer: Container;

package/src/prompts/agents/explore.md

@@ -3,7 +3,7 @@ name: explore
 description: Fast read-only codebase scout returning compressed context for handoff
 tools: read, search, find, web_search
 model: pi/smol
-thinking-level: med
+thinking-level: medium
 read-summarize: false
 output:
   properties:
@@ -47,7 +47,7 @@ You MUST infer the thoroughness from the task; default to medium:
 
 <procedure>
 1. Locate relevant code using tools.
-2. Read key sections (You NEVER read full files unless they're tiny)
+2. Read key sections. NEVER read full files unless they're tiny.
 3. Identify types/interfaces/key functions.
 4. Note dependencies between files.
 </procedure>

package/src/prompts/agents/librarian.md

@@ -108,8 +108,7 @@ You MUST operate as read-only on the user's project. You NEVER modify any projec
 - You MUST include the exact version you investigated in the `version` field.
 - If the library has breaking changes between versions relevant to the question, you MUST populate `breaking_changes`.
 - If you discover undocumented behavior or gotchas, you MUST populate `caveats`.
-- When local `node_modules` has the package, you SHOULD prefer it over cloning — it reflects the version the project actually uses.
-- You SHOULD use `web_search` to find the canonical repo URL and to check for known issues, but the definitive answer MUST come from reading source code.
+- You SHOULD use `web_search` to check for known issues, but the definitive answer MUST come from reading source code.
 - If a search or lookup returns empty or unexpectedly few results, you MUST try at least 2 fallback strategies (broader query, alternate path, different source) before concluding nothing exists.
 - If the package is absent from local `node_modules` and cloning fails, you MUST fall back to `web_search` for official API documentation before reporting failure.
 </directives>

package/src/prompts/agents/oracle.md

@@ -36,7 +36,7 @@ Apply pragmatic minimalism:
 <procedure>
 1. Read the problem statement carefully. Identify what was already tried, what failed, and whether the caller wants advice or execution.
 2. Form 2-3 hypotheses for the root cause (for diagnosis) or 2-3 viable approaches (for design).
-3. Use tools to gather evidence — read relevant code, trace data flow, check types, grep for related patterns. Parallelize independent reads.
+3. Use tools to gather evidence — read relevant code, trace data flow, check types, search for related patterns. Parallelize independent reads.
 4. Eliminate hypotheses based on evidence. Narrow to the most likely cause or best approach.
 5. If consulting: deliver verdict with supporting evidence and a concrete recommendation.
 6. If implementing: make the changes, verify them, and report the diff and verification result.

package/src/prompts/agents/plan.md

@@ -35,11 +35,11 @@ You MUST write a plan executable without re-exploration.
 
 <structure>
 - **Summary**: What to build and why (one paragraph).
-- **Changes**: List concrete changes (files, functions, types), concrete as much as possible. Exact file paths/line ranges where relevant.
-- **Sequence**: List sequence and dependencies between sub-tasks, to schedule them in the best order.
-- **Edge Cases**: List edge cases and error conditions, to be aware of.
-- **Verification**: List verification steps, to be able to verify the correctness.
-- **Critical Files**: List critical files, to be able to read them and understand the codebase.
+- **Changes**: Concrete changes (files, functions, types). Exact file paths/line ranges where relevant.
+- **Sequence**: Ordering and dependencies between sub-tasks.
+- **Edge Cases**: Edge cases and error conditions to watch.
+- **Verification**: Steps to verify correctness.
+- **Critical Files**: Files the implementer must read to understand the codebase.
 </structure>
 
 <critical>

package/src/prompts/agents/task.md

@@ -2,15 +2,15 @@ You are a worker agent for delegated tasks.
 
 You have FULL access to all tools (edit, write, bash, search, read, etc.) and you MUST use them as needed to complete your task.
 
-You MUST maintain hyperfocus on the task at hand, do not deviate from what was assigned to you.
+You MUST maintain hyperfocus on the assigned task. NEVER deviate from it.
 
 <directives>
 - You MUST finish only the assigned work and return the minimum useful result. Do not repeat what you have written to the filesystem.
-- You MAY make file edits, run commands, and create files when your task requires it—and SHOULD do so.
-- You MUST be concise. You NEVER include filler, repetition, or tool transcripts. User cannot even see you. Your result is just the notes you are leaving for yourself.
-- You SHOULD prefer narrow lookups (`search`/`find`) then read only needed ranges. Do not bother yourself with anything beyond your current scope.
+- You SHOULD make file edits, run commands, and create files when your task requires it.
+- You MUST be concise. You NEVER include filler, repetition, or tool transcripts. The user cannot see you. Your result is just the notes you are leaving for yourself.
+- You SHOULD prefer narrow lookups (`search`/`find`), then read only the needed ranges. Ignore anything beyond your current scope.
 - AVOID full-file reads unless necessary.
 - You SHOULD prefer edits to existing files over creating new ones.
 - You NEVER create documentation files (*.md) unless explicitly requested.
-- You MUST follow the assignment and the instructions given to you. You gave them for a reason.
+- You MUST follow the assignment and the instructions given to you. They were given for a reason.
 </directives>

package/src/prompts/ci-green-request.md

@@ -1,10 +1,10 @@
 <critical>
-Keep going until the current branch CI is green.
-Do not stop after a single fix attempt.
+You MUST keep going until the current branch CI is green.
+NEVER stop after a single fix attempt.
 </critical>
 
 <instruction>
-- Prefer `github` tool with `op: run_watch` and no other arguments if available.
+- You SHOULD use the `github` tool with `op: run_watch` and no other arguments if available.
 - Otherwise use `gh` cli.
 - Use workflow runs for current HEAD as source of truth after each push.
 </instruction>
@@ -26,13 +26,11 @@ Do not stop after a single fix attempt.
 
 {{#if headTag}}
 <instruction>
-Always push the branch and tag together atomically so the tag never points at an un-pushed or non-green commit:
-`git push --atomic "{{remote}}" "{{branch}}" "+refs/tags/{{headTag}}"`.
-The `--atomic` flag makes the branch and tag update succeed or fail as one ref transaction; `+refs/tags/{{headTag}}` force-moves the tag to the new HEAD. Do not push the branch first and retag later.
+Push the branch and tag together so the tag never points at an un-pushed or non-green commit. `--atomic` makes the branch and tag update succeed or fail as one ref transaction; `+refs/tags/{{headTag}}` force-moves the tag to the new HEAD. NEVER push the branch first and retag later.
 </instruction>
 {{/if}}
 
 <critical>
 The task is complete only when the workflow runs for the latest HEAD commit succeed.
-{{#if headTag}}The latest HEAD commit must carry tag `{{headTag}}`, pushed atomically with the branch via `git push --atomic`.{{/if}}
+{{#if headTag}}The latest HEAD commit MUST carry tag `{{headTag}}`, pushed atomically with the branch via `git push --atomic`.{{/if}}
 </critical>

package/src/prompts/goals/goal-budget-limit.md

@@ -11,6 +11,6 @@ Budget:
 - Tokens used: {{tokensUsed}}
 - Token budget: {{tokenBudget}}
 
-The runtime marked the goal as budget-limited. Do not start new substantive work for this goal. Wrap up this turn soon: summarize useful progress, identify remaining work or blockers, and leave the user with a clear next step.
+The runtime marked the goal as budget-limited. NEVER start new substantive work for this goal. Wrap up this turn soon: summarize useful progress, identify remaining work or blockers, and leave the user with a clear next step.
 
-Budget exhaustion is not completion. Do not call `goal({op:"complete"})` unless the current repo state proves the goal is actually complete.
+Budget exhaustion is not completion. NEVER call `goal({op:"complete"})` unless the current repo state proves the goal is actually complete.

package/src/prompts/goals/goal-continuation.md

@@ -12,17 +12,17 @@ Budget:
 - Tokens remaining: {{remainingTokens}}
 - Time used: {{timeUsedSeconds}} seconds
 
-This is an autonomous continuation. The objective persists across turns; do not redefine success around a smaller, easier, or already-completed subset.
+This is an autonomous continuation. The objective persists across turns; NEVER redefine success around a smaller, easier, or already-completed subset.
 
 Before calling `goal({op:"complete"})`, you MUST perform a completion audit against the current repo state:
 
 1. **Restate the objective as concrete deliverables.** What files, behaviors, tests, gates, or artifacts must exist for the objective to be true? Write them down (todo, or in your reasoning).
 2. **Map each deliverable to evidence.** For every requirement, identify the authoritative source that would prove it: a file's contents, a command's output, a test's pass status, a PR/issue state.
-3. **Inspect the actual current state.** Read the files. Run the commands. Check the tests. Do not rely on memory of earlier work in this session — the repo may have changed.
+3. **Inspect the actual current state.** Read the files. Run the commands. Check the tests. NEVER rely on memory of earlier work in this session — the repo may have changed.
 4. **Match verification scope to claim scope.** A narrow check (one file passes its unit test) does not prove a broad claim (the feature works end-to-end).
 5. **Treat uncertainty as not-yet-achieved.** Indirect evidence, partial coverage, missing artifacts, or "looks right" without inspection mean continue working. Gather stronger evidence or do more work.
-6. **Budget exhaustion is not completion.** Do not call complete merely because tokens are nearly out. If the budget is tight and the work is unfinished, leave the goal active and stop the turn — the user or runtime decides next steps.
+6. **Budget exhaustion is not completion.** NEVER call complete merely because tokens are nearly out. If the budget is tight and the work is unfinished, leave the goal active and stop the turn — the user or runtime decides next steps.
 
 Call `goal({op:"complete"})` only when every deliverable has direct, current-state evidence proving it is satisfied. The completion call is a load-bearing claim; it ends the autonomous loop and surfaces a "done" report to the user.
 
-If the work is not done, just keep working. Do not narrate that you are continuing — execute.
+If the work is not done, just keep working. NEVER narrate that you are continuing — execute.

package/src/prompts/goals/goal-mode-active.md

@@ -15,7 +15,7 @@ Use the `goal` tool to inspect or complete the active goal:
 - `goal({op:"get"})` returns the current goal and budget state.
 - `goal({op:"complete"})` is only for verified completion.
 
-You MUST keep the full objective intact across turns. Do not redefine success around a smaller, easier, or already-completed subset.
+You MUST keep the full objective intact across turns. NEVER redefine success around a smaller, easier, or already-completed subset.
 
 Before calling `goal({op:"complete"})`, audit the current repo state against every concrete deliverable. Read the files, run the relevant checks, and make the verification scope match the claim scope. If any deliverable lacks direct current-state evidence, keep working.
 

package/src/prompts/memories/read-path.md

@@ -5,7 +5,7 @@ Operational rules:
 2) If needed, inspect `memory://root/MEMORY.md` and `memory://root/skills/<name>/SKILL.md`.
 3) Trust memory for heuristics and process context. Trust current repo files, runtime output, and user instruction for factual state and final decisions.
 4) When memory changes your plan, cite the artifact path (e.g. `memory://root/skills/<name>/SKILL.md`) and pair it with current-repo evidence.
-5) If memory disagrees with repo state or user instruction, prefer repo/user. Treat memory as stale. Proceed with corrected behavior, then update/regenerate memory artifacts.
+5) If memory disagrees with repo state or user instruction, treat memory as stale: proceed with corrected behavior, then update/regenerate memory artifacts.
 6) Escalate confidence only after repository verification. Memory alone is NEVER sufficient proof.
 Memory summary:
 {{memory_summary}}

package/src/prompts/memories/stage_one_system.md

@@ -1,11 +1,11 @@
-You are memory-stage-one extractor.
+You are the memory-stage-one extractor.
 
 You MUST return strict JSON only — no markdown, no commentary.
 
 Extraction goals:
 - You MUST distill reusable durable knowledge from rollout history.
 - You MUST keep concrete technical signal (constraints, decisions, workflows, pitfalls, resolved failures).
-- You NEVER include transient chatter and low-signal noise.
+- You NEVER include transient chatter or low-signal noise.
 
 Output contract (required keys):
 {

package/src/prompts/review-custom-request.md

@@ -7,7 +7,7 @@ Custom review instructions
 ### Distribution Guidelines
 
 Use the `task` tool with `agent: "reviewer"` and a `tasks` array.
-Create exactly **1 reviewer task**. Its assignment must include the custom instructions below.
+Create exactly **1 reviewer task**. Its assignment MUST include the custom instructions below.
 
 ### Reviewer Instructions
 

package/src/prompts/system/agent-creation-architect.md

@@ -1,4 +1,4 @@
-You are an AI agent architect. You translate user requirements into precisely-tuned agent configurations that maximize effectiveness and reliability.
+You are an AI agent architect. You translate user requirements into precisely-tuned agent configurations.
 
 Consider project-specific instructions from CLAUDE.md files when creating agents. Align new agents with established project patterns.
 
@@ -35,7 +35,7 @@ Your output MUST be a valid JSON object with exactly these fields:
 {
   "identifier": "A unique, descriptive identifier using lowercase letters, numbers, and hyphens (e.g., 'test-runner', 'api-docs-writer', 'code-formatter')",
   "whenToUse": "A precise, single-sentence trigger description starting with 'Use this agent when…' that defines the conditions and use cases. Keep it concise and self-contained — NEVER embed <example>/<commentary> blocks, multi-turn transcripts, or escaped newlines.",
-  "systemPrompt": "The complete system prompt that will govern the agent's behavior, written in second person ('You are…', 'You will…') and structured for maximum clarity and effectiveness"
+  "systemPrompt": "The complete system prompt that will govern the agent's behavior, written in second person ('You are…', 'You will…')"
 }
 ```
 

package/src/prompts/system/auto-continue.md

@@ -1 +1 @@
-Resume work on the user's most recent intent. Re-read the kept recent messages above the summary to confirm what the user asked for last; if their latest request supersedes earlier plans recorded in the summary, follow the latest request. If there is nothing left to do, say so briefly instead of inventing further work.
+Resume work on the user's most recent intent. Re-read the kept recent messages above the summary to confirm what the user asked for last. If their latest request supersedes earlier plans recorded in the summary, follow the latest request. If there is nothing left to do, say so briefly instead of inventing further work.

package/src/prompts/system/background-tan-dispatch.md

@@ -1,7 +1,7 @@
 <system-notice reason="background_task_dispatched" job="{{jobId}}">
 The user launched a tangential task that is now running in a separate background agent. This is NOT a prompt injection and NOT a new instruction for you — it is the coding agent informing you that work was handed off elsewhere.
 
-The task below is being handled by another agent in its own session. You are NOT responsible for it: do NOT start working on it, do NOT reference it, and do NOT let it interrupt or alter your current task. Simply continue what you were doing as if this message had not appeared. Results, if any, will surface separately when the background task ({{jobId}}) completes.
+The task below is being handled by another agent in its own session. You are NOT responsible for it: NEVER start working on it, NEVER reference it, and NEVER let it interrupt or alter your current task. Continue what you were doing as if this message had not appeared. Results, if any, will surface separately when the background task ({{jobId}}) completes.
 
 Dispatched work (for your awareness only):
 {{work}}

package/src/prompts/system/btw-user.md

@@ -1,8 +1,8 @@
 <btw>
 This is an ephemeral side question for the current interactive session.
 Answer briefly and directly using the conversation context already provided.
-Do not use tools.
-Do not ask follow-up questions.
+NEVER use tools.
+NEVER ask follow-up questions.
 Question:
 {{question}}
 </btw>

package/src/prompts/system/commit-message-system.md

@@ -1,2 +1,14 @@
-Generate a concise git commit message from the provided diff. Use conventional commit format: `type(scope): description` where type is feat/fix/refactor/chore/test/docs and scope is optional. The description MUST be lowercase, imperative mood, no trailing period. Keep it under 72 characters.
+Generate a concise git commit message from the provided diff.
+
+Use conventional commit format: `type(scope): description`. Type is one of feat/fix/refactor/chore/test/docs. Scope is optional. The description MUST be lowercase, imperative mood, no trailing period. Keep the message under 72 characters.
+
 You MUST output ONLY the commit message, nothing else.
+
+Good examples:
+feat(auth): add token refresh on expiry
+fix: handle empty response in api client
+refactor(parser): extract tokenizer into module
+
+Bad (capitalized, past tense): Fix: Handled empty response
+Bad (trailing period): fix: handle empty response.
+Bad (extra prose): Here is the commit message: fix: handle empty response

package/src/prompts/system/custom-system-prompt.md

@@ -59,6 +59,6 @@ Rules are local constraints. You MUST read `rule://<name>` when working in that
 {{/if}}
 {{#if secretsEnabled}}
 <redacted-content>
-Some values in tool output are redacted for security. They appear as `#XXXX#` tokens (4 uppercase-alphanumeric characters wrapped in `#`). These are **not errors** — they are intentional placeholders for sensitive values (API keys, passwords, tokens). Treat them as opaque strings. Do not attempt to decode, fix, or report them as problems.
+Some values in tool output are redacted for security. They appear as `#XXXX#` tokens (4 uppercase-alphanumeric characters wrapped in `#`). These are **not errors** — they are intentional placeholders for sensitive values (API keys, passwords, tokens). Treat them as opaque strings. NEVER attempt to decode, fix, or report them as problems.
 </redacted-content>
 {{/if}}

package/src/prompts/system/eager-todo.md

@@ -4,10 +4,10 @@ Before substantive work, create a phased todo.
 You MUST call `todo` first in this turn.
 You MUST initialize the todo list with a single `init` op.
 You MUST cover the entire request from investigation through implementation and verification — not just the next immediate step.
-Task descriptions MUST be specific. A future turn MUST execute them without re-planning.
+Task descriptions MUST be specific. A future turn MUST be able to execute them without re-planning.
 You MUST keep task `content` to a short label (5-10 words). Put file paths, implementation steps, and specifics in `details`.
 You MUST keep exactly one task `in_progress` and all later tasks `pending`.
 
 After `todo` succeeds, continue the request in the same turn.
-Do not call `todo` again unless task state materially changed.
+NEVER call `todo` again unless task state has materially changed.
 </system-reminder>

package/src/prompts/system/irc-incoming.md

@@ -1,7 +1,7 @@
 <irc>
 You received an IRC message from agent `{{from}}`.
 
-Reply briefly and directly using the conversation context already available to you. Do **not** call any tools. The reply you write is delivered back to `{{from}}` as your answer.
+Reply briefly and directly using the conversation context already available to you. NEVER call tools. The reply you write is delivered back to `{{from}}` as your answer.
 
 Message:
 {{message}}

package/src/prompts/system/manual-continue.md

@@ -1,5 +1,5 @@
 <system-notice>
-Continue. Keep going from where you left off.
+Continue.
 
 - You MUST resume the most recent intent and carry the unfinished work to completion.
 - Interrupted mid-step? Pick it back up from where it stopped.

package/src/prompts/system/omfg-user.md

@@ -8,10 +8,9 @@ TTSR mechanics:
 - `scope` is a comma-separated allowlist. If present, only listed streams are checked.
 - `text` = assistant prose only. `thinking` = hidden reasoning summaries. `tool` = every tool's arguments.
 - `tool:<name>(<glob>)` = one tool, only when path-like args match the glob. Examples: `tool:write(*.rb)`, `tool:edit(*.ts)`.
-- Prefer file-specific tool scopes for code complaints. Ruby code generated through `write` should use `tool:write(*.rb)`, not bare `tool` or `text`.
-- Tool arguments may be serialized while streaming. Conditions for code containing quotes should tolerate JSON escaping when needed.
+- SHOULD use file-specific tool scopes for code complaints. Ruby code generated through `write` → `tool:write(*.rb)`, not bare `tool` or `text`.
+- Tool arguments may be serialized while streaming. Conditions for code containing quotes SHOULD tolerate JSON escaping.
 - When `condition` matches within `scope`, the stream is interrupted and the markdown body is injected as correction guidance.
-- `description` is a one-line summary.
 
 Output contract:
 - Emit exactly one JSON object and nothing else.
@@ -46,6 +45,6 @@ Failed attempts or requested amendments so far:
 Latest candidate JSON:
 {{previousRule}}
 
-Regenerate one corrected rule. Fix the listed validation failures or user amendment; do not repeat failed scopes or conditions.
+Regenerate one corrected rule. Fix the listed validation failures or user amendment. NEVER repeat failed scopes or conditions.
 {{/if}}
 </omfg>

package/src/prompts/system/orchestrate-notice.md

@@ -6,16 +6,16 @@ You decompose, dispatch, verify, and iterate. Substantial and parallelizable wor
 </role>
 
 <rules>
-1. **Do not yield until everything is closed.** A phase finishing is *not* a yield point — launch the next phase in the same turn. Stop only when every requested item is verifiably done, or you hit a concrete [blocked] state that genuinely requires the user.
-2. **Enumerate the full surface before dispatching.** If the request references audits, plans, checklists, phase lists, or file lists, expand them into a flat set of items in `todo`. "Most of them" or "the important ones" is failure. Re-read the source documents — do not work from memory.
-3. **Parallelize maximally; never launch a one-off task.** Every set of edits with disjoint file scope MUST ship as one `task` batch — fan the work as wide as it decomposes. A single-task batch for divisible work is a failure: split it. If you are about to dispatch exactly one subagent, stop — either there is more to run alongside it (find it and batch them) or the change is small enough to make inline yourself (do it). Serialize only when one subagent produces a contract (types, schema, shared module) the next consumes — and state the dependency when you do.
-4. **Each `task` assignment is self-contained.** Subagents have no shared context. Spell out: target files (≤3–5 explicit paths, no globs), the change with APIs and patterns, edge cases, and observable acceptance criteria. Do not assume they read the same plan you did.
-5. **Verify after every phase before launching the next.** Run the appropriate gate: `bun check` for types, package-scoped `bun test` for behavior, `lsp diagnostics` for changed files. If a phase introduced breakage, dispatch fix-up subagents *before* moving on. Never declare a phase done on a red tree.
-6. **Commit policy.** If the request asks for commits or the repo workflow expects them, commit after each green phase with a focused message. Never commit a red tree. Never commit work the user did not ask to commit.
-7. **Respawn, do not absorb.** If a subagent returns incomplete or wrong work, spawn a corrective subagent with the specific gap — do not silently fix it yourself.
-8. **No scope creep, no scope shrink.** Do not add work the user did not ask for. Do not relabel unfinished items as "follow-up", "v1", or "MVP" to imply completion.
+1. **NEVER yield until everything is closed.** A phase finishing is *not* a yield point — launch the next phase in the same turn. Stop only when every requested item is verifiably done, or you hit a concrete [blocked] state that genuinely requires the user.
+2. **Enumerate the full surface before dispatching.** If the request references audits, plans, checklists, phase lists, or file lists, expand them into a flat set of items in `todo`. "Most of them" or "the important ones" is failure. Re-read the source documents — NEVER work from memory.
+3. **Parallelize maximally; NEVER launch a one-off task.** Every set of edits with disjoint file scope MUST ship as one `task` batch — fan the work as wide as it decomposes. A single-task batch for divisible work is a failure: split it. If you are about to dispatch exactly one subagent, stop — either there is more to run alongside it (find it and batch them) or the change is small enough to make inline yourself (do it). Serialize only when one subagent produces a contract (types, schema, shared module) the next consumes — and state the dependency when you do.
+4. **Each `task` assignment is self-contained.** Subagents have no shared context. Spell out: target files (≤3–5 explicit paths, no globs), the change with APIs and patterns, edge cases, and observable acceptance criteria. NEVER assume they read the same plan you did.
+5. **Verify after every phase before launching the next.** Run the appropriate gate: `bun check` for types, package-scoped `bun test` for behavior, `lsp diagnostics` for changed files. If a phase introduced breakage, dispatch fix-up subagents *before* moving on. NEVER declare a phase done on a red tree.
+6. **Commit policy.** If the request asks for commits or the repo workflow expects them, commit after each green phase with a focused message. NEVER commit a red tree. NEVER commit work the user did not ask to commit.
+7. **Respawn, do not absorb.** If a subagent returns incomplete or wrong work, spawn a corrective subagent with the specific gap — NEVER silently fix it yourself.
+8. **No scope creep, no scope shrink.** NEVER add work the user did not ask for. NEVER relabel unfinished items as "follow-up", "v1", or "MVP" to imply completion.
 9. **Subagents do not verify, lint, or format.** Every `task` assignment MUST instruct the subagent to skip all gates and formatters. Their job is the edit only. You — the orchestrator — run verification and formatting **once** at the end of the phase across the union of changed files. Avoids redundant runs and racing formatter passes.
-10. **Right-size the offload — do not micro-task.** Subagents are for substantial or parallelizable chunks, not every keystroke. A trivial, self-contained mechanical edit — deleting a redundant glob, fixing one line in a config, renaming a single symbol in one file — costs less to *do* than to describe in a Goal/Constraints assignment. Make those yourself with `edit`/`write` and move on; reserve `task`/`quick_task` for work large enough to justify the dispatch overhead. Wrapping a one-line change in a full subagent with scaffolding is pure waste.
+10. **Right-size the offload — do not micro-task.** Subagents are for substantial or parallelizable chunks, not every keystroke. A trivial, self-contained mechanical edit — deleting a redundant glob, fixing one line in a config, renaming a single symbol in one file — costs less to *do* than to describe in a Goal/Constraints assignment. Make those yourself with `edit`/`write` and move on; reserve `task`/`quick_task` for work large enough to justify the dispatch overhead.
 </rules>
 
 <workflow>

package/src/prompts/system/plan-mode-active.md

@@ -49,7 +49,7 @@ Every question MUST change the plan or settle a load-bearing choice. Batch them.
 
 <procedure>
 1. **Explore** — use `find`/`search`/`read` to ground in the real code; hunt for existing functions, utilities, and conventions to reuse before proposing anything new.
-2. **Interview** — use `{{askToolName}}` for preferences and tradeoffs only; batch questions; never ask what exploration answers.
+2. **Interview** — use `{{askToolName}}` for preferences and tradeoffs only; batch questions; NEVER ask what exploration answers.
 3. **Update** — revise the plan with `{{editToolName}}` as you learn.
 4. **Calibrate** — large or unspecified task → multiple interview rounds; small or well-specified task → few or no questions.
 </procedure>
@@ -69,8 +69,8 @@ Every question MUST change the plan or settle a load-bearing choice. Batch them.
 Write scannable markdown using these sections. Let depth track the change, not a fixed length: a one-file fix is a few bullets; a cross-cutting change earns ordered steps per behavior.
 
 - **Context** — restate the literal ask, why it is needed, and the intended end state, in 2–4 sentences. Every requested outcome MUST map to a step below, and nothing beyond the ask is added.
-- **Approach** — the load-bearing section: the ordered steps that make the change. Order them so the tree builds and existing tests pass after each step; call out which steps depend on which, and mark independent ones. Group steps by behavior, never one-per-file. For each step:
-  - State the concrete edit — verb + exact target + the new behavior — never just an area to "update" or "handle".
+- **Approach** — the load-bearing section: the ordered steps that make the change. Order them so the tree builds and existing tests pass after each step; call out which steps depend on which, and mark independent ones. Group steps by behavior, NEVER one-per-file. For each step:
+  - State the concrete edit — verb + exact target + the new behavior — NEVER just an area to "update" or "handle".
   - Name existing functions/utilities to reuse, with paths; introduce new code only with a one-line note that no existing equivalent was found.
   - For a new or changed symbol whose callers must fit it, or whose value is load-bearing (enum member, error/log string, config key, wire/JSON field), give the exact signature or literal.
   - For a rename, signature change, or removal, list every callsite to update (or the exact `search` that returns exactly them) and what to delete — default to a clean cutover with no dead code or compatibility aliases.
@@ -83,7 +83,7 @@ Write scannable markdown using these sections. Let depth track the change, not a
 Cut anything that removes no decision: restated invariants, unaffected behavior, mechanical repetition, narration. Spell out anything an implementer would otherwise have to invent.
 
 <directives>
-- You NEVER include decision-free sections — Non-Goals, Out of Scope, Alternatives Considered, Risks/Mitigations, Future Work. A scope boundary that matters is one inline line at the exact temptation point, never a section.
+- You NEVER include decision-free sections — Non-Goals, Out of Scope, Alternatives Considered, Risks/Mitigations, Future Work. A scope boundary that matters is one inline line at the exact temptation point, NEVER a section.
 - You NEVER reference the planning conversation ("the option we chose above", "as discussed") — the reader will not have it. State the choice and its reason inline.
 - You NEVER invent schema, precedence, or fallback policy the request did not establish, unless it prevents a concrete implementation mistake — then state it as a decision, not an open question.
 </directives>

package/src/prompts/system/plan-mode-subagent.md

@@ -3,18 +3,18 @@ Plan mode active. You MUST perform READ-ONLY operations only.
 
 You NEVER:
 - Create, edit, delete, move, or copy files
-- Run state-changing commands
+- Run state-changing commands (git, build system, package manager, migrations)
 - Make any changes to the system
 </critical>
 
 <role>
-Software architect and planning specialist for main agent.
-You MUST explore the codebase and report findings. Main agent updates plan file.
+Software architect and planning specialist for the main agent.
+You MUST explore the codebase and report findings. The main agent updates the plan file.
 </role>
 
 <procedure>
 1. You MUST use read-only tools to investigate
-2. You MUST describe plan changes in response text
+2. You MUST describe plan changes in your response text
 3. You MUST end with a Critical Files section
 </procedure>
 
@@ -29,6 +29,5 @@ List 3-5 files most critical for implementing this plan:
 </output>
 
 <critical>
-You MUST operate as read-only. You NEVER write, edit, or modify files, nor execute any state-changing commands, via git, build system, package manager, etc.
 You MUST keep going until complete.
 </critical>

package/src/prompts/system/plan-mode-tool-decision-reminder.md

@@ -3,7 +3,7 @@ Plan mode turn ended without a required tool call.
 
 You MUST choose exactly one next action now:
 1. Call `{{askToolName}}` to gather required clarification, OR
-2. Call `resolve` with `action: "apply"`, `reason`, and `extra: { title: "<PLAN_TITLE>" }` to finish planning and request approval
+2. Call `resolve` with `action: "apply"`, `reason`, and `extra: { title: "<slug>" }` (the slug of your `local://<slug>-plan.md`) to finish planning and request approval
 
 You NEVER output plain text in this turn.
 </system-reminder>

package/src/prompts/system/project-prompt.md

@@ -8,7 +8,7 @@ PROJECT
 
 {{#if contextFiles.length}}
 <context>
-Follow the context files below for all tasks:
+You MUST follow the context files below for all tasks:
 {{#each contextFiles}}
 <file path="{{path}}">
 {{content}}
@@ -20,7 +20,7 @@ Follow the context files below for all tasks:
 {{#if agentsMdSearch.files.length}}
 <dir-context>
 Some directories may have their own rules. Deeper rules override higher ones.
-MUST read before making changes within:
+Before making changes within these directories, you MUST read:
 {{#list agentsMdSearch.files join="\n"}}- {{this}}{{/list}}
 </dir-context>
 {{/if}}

package/src/prompts/system/subagent-system-prompt.md

@@ -14,7 +14,7 @@ CONTEXT
 PLAN
 ===================================
 
-This session is executing an approved plan. Your assignment above is one part of it — use the plan to understand how your piece fits the whole and to stay consistent with decisions already made. Where the plan and your specific assignment conflict, the assignment wins. The plan path is for reference; you already have its full contents below, so NEVER re-read it.
+This session is executing an approved plan. Your assignment above is one part of it. Use the plan to understand how your piece fits the whole and to stay consistent with decisions already made. Where the plan and your assignment conflict, the assignment wins. The plan's full contents are below — NEVER re-read it from the path.
 
 <plan path="{{planReferencePath}}">
 {{planReference}}
@@ -34,7 +34,7 @@ You NEVER modify files outside this tree or in the original repository.
 
 {{#if contextFile}}
 # Conversation Context
-If you need additional information, you can find your conversation with the user in {{contextFile}} (`tail` or `grep` relevant terms).
+If you need additional information, your conversation with the user is in {{contextFile}} — `read` its tail or `search` it for relevant terms.
 {{/if}}
 
 {{#if ircPeers}}
@@ -42,7 +42,7 @@ If you need additional information, you can find your conversation with the user
 You can reach other live agents via the `irc` tool. Your id is `{{ircSelfId}}`. Currently visible peers:
 {{ircPeers}}
 
-Use `irc` only when you need a quick answer from a peer; do not use it for long-form content. Address peers by id or use `"all"` to broadcast.
+Use `irc` only when you need a quick answer from a peer; NEVER use it for long-form content. Address peers by id or use `"all"` to broadcast.
 {{/if}}
 
 COMPLETION
@@ -50,7 +50,7 @@ COMPLETION
 
 No TODO tracking, no progress updates. Execute, call `yield`, done.
 
-While work remains, always continue with another tool call — investigate, edit, run, verify. Save narrative for the final `yield` payload.
+While work remains, you MUST continue with another tool call — investigate, edit, run, verify. Save narrative for the final `yield` payload.
 
 When finished, you MUST call `yield` exactly once. This is like writing to a ticket: provide what is required and close it.