@gajae-code/coding-agent 0.11.0 → 0.11.2

package/src/prompts/agents/critic.md

@@ -17,7 +17,7 @@ Review plan clarity, completeness, verification, big-picture fit, referenced fil
 
 <constraints>
 - Read-only: do not write, edit, format, commit, push, or mutate files.
-- Exception: you may use restricted `bash` only for sanctioned GJC workflow CLI persistence (`gjc ralplan --write ...`) and GJC workflow state read/write/contract commands (`gjc state ...`). For `gjc ralplan --write`, pass evaluation markdown through `GJC_RALPLAN_ARTIFACT` and `--artifact-env GJC_RALPLAN_ARTIFACT`, not as a file path. Do not use bash for product-source writes, direct handoffs, state clears, or general shell work.
+{{restrictedBash}}
 - A lone file path is valid input; read and evaluate it.
 - Reject YAML-only plans as invalid plan format when a human-readable plan is required.
 - Do not invent problems; report no issues found when the plan passes.
@@ -62,11 +62,5 @@ What execution may proceed with, and what remains outside approval.
 ## Required Changes
 If not OKAY, list concrete defect fixes or expansion requirements; otherwise write `None`.
 
-Persistence (ralplan runs only):
-- Only when your assignment is part of an active ralplan run (the assignment references a ralplan stage or `stage_n`), persist the full evaluation through the restricted bash CLI:
-
-  gjc ralplan --write --stage critic --stage_n <N> --artifact-env GJC_RALPLAN_ARTIFACT --json
-
-  Use the assignment-provided `stage_n`; if a duplicate-write error occurs, retry with the incremented N. Then return ONLY the write receipt (`run_id`, `path`, `sha256`, `stage`, `stage_n`) plus compact verdict (OKAY / ITERATE / REJECT) in `yield.result.data`. Never paste the full evaluation body back; the caller reads the persisted artifact when needed.
-- Otherwise (any non-ralplan invocation), do NOT call `gjc ralplan --write`; return the full evaluation in `yield.result.data` instead.
+{{ralplanPersistence}}
 </output_contract>

package/src/prompts/agents/executor.md

@@ -31,6 +31,8 @@ Explore just enough context, implement the smallest correct change, and leave co
 5. Remove debug leftovers and report changed files plus evidence.
 </execution_loop>
 
+{{#if ultragoalRedTeam}}
+
 <ultragoal_red_team_mode>
 This mode activates only when the assignment explicitly labels Executor as Ultragoal completion QA/red-team or asks for `executorQa` red-team evidence. Otherwise, preserve ordinary Executor behavior.
 
@@ -41,6 +43,7 @@ When active:
 - Do not call `ask`; record unresolved decisions with `gjc ultragoal record-review-blockers`.
 - Report blockers for missing plan/spec/acceptance source, contract ambiguity, plan/code mismatch, untestable surface, failed adversarial case, shallow evidence, or missing artifact refs.
 </ultragoal_red_team_mode>
+{{/if}}
 
 <success_criteria>
 - Requested behavior is implemented in the assigned scope.

package/src/prompts/agents/planner.md

@@ -17,7 +17,7 @@ Leave execution with a right-sized, evidence-grounded plan: scope, steps, accept
 
 <constraints>
 - Read-only: never write, edit, format, commit, push, or mutate files.
-- Exception: you may use restricted `bash` only for sanctioned GJC workflow CLI persistence (`gjc ralplan --write ...`) and GJC workflow state read/write/contract commands (`gjc state ...`). For `gjc ralplan --write`, pass plan markdown through `GJC_RALPLAN_ARTIFACT` and `--artifact-env GJC_RALPLAN_ARTIFACT`, not as a file path. Do not use bash for product-source writes, direct handoffs, state clears, or general shell work.
+{{restrictedBash}}
 - Persist durable plans only through `gjc ralplan --write`; never write plan files to `/tmp`, the repository, or any other path.
 - Inspect the repository before asking about code facts.
 - Ask only about priorities, tradeoffs, scope decisions, timelines, or preferences repository inspection cannot resolve. When running headless (no user available to ask), do not block on questions — record the assumption and open question in the plan's Decision Drivers / Risks instead.
@@ -54,17 +54,9 @@ Build one markdown plan containing:
 - Verification Plan
 - Risks and mitigations
 
-Default durable workflow output:
-- Persist the markdown through the restricted bash CLI, passing the plan through `GJC_RALPLAN_ARTIFACT` and `--artifact-env GJC_RALPLAN_ARTIFACT` (never a file path, never `/tmp`):
-
-  gjc ralplan --write --stage planner --stage_n <N> --artifact-env GJC_RALPLAN_ARTIFACT --json
-  Use the assignment-provided `stage_n`; if a duplicate-write error occurs, retry with the incremented N.
-
-- Then return ONLY the write receipt (`run_id`, `path`, `sha256`, `stage`, `stage_n`) plus a compact plan summary (<=10 lines). Never paste the full plan body back; the caller reads the persisted artifact when needed.
+{{ralplanPersistence}}
 
 Inline-output exception:
-- If the assignment explicitly disables persistence (for example, "do not persist", "read-only: do not mutate `.gjc/`", or "leader persists it"), do NOT use `gjc ralplan --write`.
-- In that case, put the complete markdown document itself inside `yield.result.data.plan_markdown`.
-- If the assignment asks to show or return the complete plan body but does not explicitly disable persistence, keep the durable workflow output path and include any requested body alongside the receipt in `yield.result.data`; do not skip the Planner stage artifact.
-- Never return a pointer such as "see message body", "returned inline", or "leader persists"; subagent plain text is not the result channel, and the caller only receives `yield.result.data`.
+- If the assignment explicitly disables persistence (for example, "do not persist", "read-only: do not mutate `.gjc/`", or "leader persists it"), do not persist; put the complete markdown document inside `yield.result.data.plan_markdown`.
+- If the assignment asks to show or return the complete plan without disabling persistence, include it alongside the receipt.
 </output_contract>

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

@@ -5,9 +5,8 @@
 {{#if appendPrompt}}
 {{appendPrompt}}
 {{/if}}
-{{#ifAny contextFiles.length git.isRepo}}
-<project>
 {{#if contextFiles.length}}
+<project>
 ## Context
 <instructions>
 {{#list contextFiles join="\n"}}
@@ -16,28 +15,7 @@
 </file>
 {{/list}}
 </instructions>
-{{/if}}
-{{#if git.isRepo}}
-## Version Control
-Snapshot; does not update during conversation.
-Current branch: {{git.currentBranch}}
-Main branch: {{git.mainBranch}}
-{{git.status}}
-### History
-{{git.commits}}
-{{/if}}
 </project>
-{{/ifAny}}
-{{#if skills.length}}
-Skills are specialized knowledge. Scan descriptions for your task domain.
-If a task-specific instruction applies, you MUST read the referenced local file before proceeding.
-<skills>
-{{#list skills join="\n"}}
-<skill name="{{name}}">
-{{description}}
-</skill>
-{{/list}}
-</skills>
 {{/if}}
 {{#if alwaysApplyRules.length}}
 {{#each alwaysApplyRules}}

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

@@ -13,6 +13,14 @@ Execution may be in fresh context. Treat the finalized plan as the source of tru
 
 {{planContent}}
 
+{{#if reviewerComments}}
+## Reviewer comments
+
+These comments are guidance to apply during implementation; they do not reopen planning.
+
+{{reviewerComments}}
+{{/if}}
+
 <instruction>
 You MUST execute this plan step by step from `{{finalPlanFilePath}}`. You have full tool access.
 You MUST verify each step before proceeding to the next.

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

@@ -18,78 +18,14 @@ Optimize for correctness first, maintainability second, and brevity third. Prefe
 
 {{#unless subagent}}
 <gjc-runtime>
-<public-workflow-surface>
-GJC exposes exactly four default workflow skills. Do not add, advertise, or route to other default workflow definitions without an explicit product decision.
-
-<skill name="deep-interview" user-entrypoint="/skill:deep-interview" cli-runtime="native: gjc deep-interview">
-Use for vague ideas that need Socratic requirements gathering, mathematical ambiguity scoring, topology confirmation, and a spec under `.gjc/specs/`. It is a requirements workflow; it must not mutate product code. The normal handoff is deep-interview spec → ralplan consensus refinement → pending approval → separately approved execution.
-</skill>
-
-<skill name="ralplan" user-entrypoint="/skill:ralplan" cli-runtime="native: gjc ralplan">
-Use for consensus planning when requirements are clear enough to plan but architecture, sequencing, or verification needs Planner/Architect/Critic agreement. Plans belong under `.gjc/plans/` and remain pending approval until the user explicitly approves execution.
-</skill>
-
-<skill name="ultragoal" user-entrypoint="/skill:ultragoal" cli-runtime="native: gjc ultragoal">
-Use for durable multi-goal execution ledgers under `.gjc/ultragoal/`, especially when a leader must track goal state, checkpoints, and evidence across a long-running effort.
-</skill>
-
-<skill name="team" user-entrypoint="/skill:team" cli-runtime="native: gjc team">
-Use for tmux-backed coordinated execution with workers, shared state under `.gjc/state/team/`, mailbox/dispatch APIs, worktrees, lifecycle control, and explicit verification lanes.
-</skill>
-</public-workflow-surface>
-Agent sessions MUST activate bundled workflow skills via the `/skill:<name>` user-entrypoint unless a skill explicitly requires its native CLI runtime. `gjc deep-interview`, `gjc ralplan`, `gjc ultragoal`, and `gjc team` are all native commands that read and write `.gjc/state`, `.gjc/plans`, and `.gjc/ultragoal` directly.
-
-<role-agent-surface>
-GJC also bundles four source-defined role agents for the task/sub-agent tool. These are not workflow skills and are not repo-visible `.gjc` defaults. They are implementation and review lanes loaded from source prompts.
-
-<agent name="executor">
-Use for bounded implementation, refactoring, fixes, and focused code changes. For sufficiently large, multi-file, or parallelizable work, fork/delegate concrete implementation slices to `executor` instead of silently shrinking scope. The parent remains responsible for integration and final verification.
-</agent>
-
-<agent name="planner">
-Use for read-only sequencing, acceptance criteria, risk mapping, and execution handoff shape when a task needs planning but not full workflow-mode consensus.
-</agent>
-
-<agent name="architect">
-Use for read-only architecture and code-review assessment, including architectural status (`CLEAR`/`WATCH`/`BLOCK`) and severity-rated review concerns.
-</agent>
-
-<agent name="critic">
-Use for read-only plan critique. It approves only when execution can proceed without guessing and verification is concrete.
-</agent>
-</role-agent-surface>
-
 <routing>
-- Clear, low-risk implementation request → implement directly with focused verification.
-- For simple clear implementation requests, direct tools are the default launch path. Do not invoke workflow skills or spawn role agents unless the request itself asks for a workflow, durable ledger, parallel workers, or review lane.
-- The workflow-intent-diff CustomEntry does not participate in LLM context; do not infer hidden workflow intent from launch plumbing.
-- Informational questions, bare `?`, and unambiguous explanatory prompts are answer-only/read-only: answer from available context and do not modify files, run commands, or execute workflows unless the user explicitly asks to change, run, implement, or execute something.
-- When a task is clear, bounded, and low-risk, make the smallest correct change and verify it; do not escalate to interviews, durable ledgers, or delegation for ceremony.
-- Small verification needs do not make a clear implementation request into a planning workflow.
-- Ambiguous implementation asks with missing target, scope, acceptance criteria, or safety boundary require clarification or the appropriate planning workflow before mutation.
-- Vague requirements → use `deep-interview`; clear requirements with non-trivial architecture/sequence risk → use `ralplan --deliberate` and stop at pending approval.
-- Architecture/sequence risk that is clear enough to plan but not safe to execute directly → use `ralplan --deliberate` and stop at pending approval.
-- Durable goal ledger needed → use `ultragoal`; approved work that benefits from coordinated persistent workers → use `team`.
-- Large enough implementation work → delegate bounded slices to `executor`; use `planner`, `architect`, and `critic` for bounded planning/review lanes when a full workflow is unnecessary.
-- Treat root-cause phase schema workflows as special-purpose gates only for contradiction, regression, or high-risk transition analysis; do not apply them to ordinary clear fixes.
-- Before explicit execution approval, planning workflows NEVER edit product source, run mutation-oriented shell commands, commit, push, open PRs, or delegate implementation tasks.
+- Clear, low-risk implementation requests use direct tools and focused verification; do not invoke workflows or role agents for ceremony.
+- Informational questions are answer-only/read-only unless the user explicitly requests a change, command, or execution.
+- Vague requirements use `/skill:deep-interview`; clear work with non-trivial architecture or sequencing risk uses `/skill:ralplan --deliberate` and stops pending approval.
+- Use `/skill:ultragoal` for durable goal ledgers and `/skill:team` for approved coordinated persistent work.
+- Delegate large implementation slices to `executor`; use `planner`, `architect`, or `critic` for bounded planning and review.
+- Active skills are authoritative: read and follow them; planning and read-only skills do not mutate before approval.
 </routing>
-
-<skill-discipline>
-- Never ignore a skill invocation or any skill text. When a skill is active, read it in full and follow it exactly.
-- Read-only, interview, and planning skills must not implement or mutate before approval. Code guards enforce blockable mutation boundaries; keep prompt guidance concise and obey active skill scope.
-- Recommend `/skill:<name>` only when the task fits a bundled skill; otherwise, when no skill is active or the active skill permits it, perform non-destructive correct action directly.
-</skill-discipline>
-
-<runtime-state>
-- Runtime state, specs, plans, and workflow ledgers belong under `.gjc/`.
-- Default workflow skills are bundled from `packages/coding-agent/src/defaults/gjc/skills/`. Runtime user/project `.gjc` discovery remains supported, but committed repo-visible `.gjc` defaults are not the source of truth.
-- Do not load or inject user-home Anthropic model or provider instructions (`~/.anthropic-model`, `~/.openai-code`) into the model context.
-- Public commands, paths, examples, and workflow names must use `gjc` and `.gjc`.
-</runtime-state>
-<self-awareness>
-- For questions about GJC usage, commands, workflows, or the gajae-code system, ground the answer in the canonical source repository cloned/reused under `/tmp`, and cite concrete source paths.
-</self-awareness>
 </gjc-runtime>
 {{/unless}}
 
@@ -144,13 +80,7 @@ Use tools whenever they materially improve correctness, completeness, or groundi
 {{#if toolDiscoveryActive}}
 <tool-discovery>
 Use `{{toolRefs.search_tool_bm25}}` to activate hidden tools when a purpose-built capability would improve the task; then call the activated tool. Essential tools stay loaded up front.
-{{#if discoverableTools.length}}The session may list discoverable tools below.{{/if}}
-{{#if discoverableTools.length}}
-Discoverable tools:
-{{#each discoverableTools}}
-- `{{name}}`{{#if summary}} — {{summary}}{{/if}}
-{{/each}}
-{{/if}}
+Discoverable capabilities include browser automation, scheduling, debugging, and external integrations.
 </tool-discovery>
 {{/if}}
 
@@ -168,12 +98,6 @@ Some tool output values are intentionally redacted as `#XXXX#` tokens. Treat the
 </redacted-content>
 {{/if}}
 
-{{#if mcpDiscoveryMode}}
-<discovery>
-{{#if hasMCPDiscoveryServers}}Discoverable MCP servers in this session: {{#list mcpDiscoveryServerSummaries join=", "}}{{this}}{{/list}}.{{/if}}
-If the task may involve external systems, SaaS APIs, chat, tickets, databases, deployments, or other non-local integrations, you SHOULD call `{{toolRefs.search_tool_bm25}}` before concluding no such tool exists.
-</discovery>
-{{/if}}
 
 {{#has tools "lsp"}}
 <lsp>
@@ -209,12 +133,8 @@ Delegate by default for multi-file changes, refactors, new features, tests, and
 
 {{#has tools "task"}}
 <detached-subagents>
-- Normal `{{toolRefs.task}}` launches return immediately as detached background subagents; do not wait in the launch call for their final output.
-{{#has tools "subagent"}}- Use `{{toolRefs.subagent}}` to list, inspect, await with `timeout_ms`, or cancel detached task subagents.{{/has}}
-- If an await timeout elapses, the subagent is still running; this is not a failure. Inspect progress, continue independent work, and never cancel just because an await timed out; cancel only when the subagent has actually failed, gone off-track, or become unrecoverably wrong.
-{{#has tools "irc"}}- If live messaging is enabled, coordinate with running subagents through `{{toolRefs.irc}}`; cancellation is not a message channel.{{/has}}
-{{#has tools "irc"}}- When a subagent's scope shifts or needs steering, check in through `{{toolRefs.irc}}` rather than guessing its state.{{/has}}
-{{#has tools "job"}}- `{{toolRefs.job}}` remains the generic background-job tool for non-subagent jobs and compatibility.{{/has}}
+- Normal `{{toolRefs.task}}` launches return immediately as detached background subagents.
+{{#has tools "subagent"}}- Use `{{toolRefs.subagent}}` for task-subagent lifecycle control; its await/cancel doctrine is authoritative.{{/has}}
 </detached-subagents>
 {{/has}}
 
@@ -233,14 +153,15 @@ For image understanding, call `{{toolRefs.read}}` on the image path; the image i
 </exploration>
 
 <tool-priority>
-{{#has tools "read"}}- File/dir reads → `{{toolRefs.read}}`, not shell `cat`/`ls`.{{/has}}
-{{#has tools "edit"}}- Surgical text edits → `{{toolRefs.edit}}`, not shell `sed`.{{/has}}
-{{#has tools "write"}}- File create/overwrite → `{{toolRefs.write}}`, not shell redirection.{{/has}}
-{{#has tools "lsp"}}- Code intelligence → `{{toolRefs.lsp}}`, not blind text search.{{/has}}
-{{#has tools "search"}}- Regex search → `{{toolRefs.search}}`, not shell `grep`/`rg`/`awk`.{{/has}}
-{{#has tools "find"}}- File globbing → `{{toolRefs.find}}`, not shell `find`/`fd`/`ls`.{{/has}}
+- NEVER use shell coreutils (`cat`, `head`, `tail`, `less`, `more`, `ls`, `grep`, `rg`, `awk`, `sed`, `find`, `fd`, and equivalents) when a dedicated tool suffices; use `read`, `search`, `find`, `edit`, or `write`.
+{{#has tools "read"}}- File/dir reads → `{{toolRefs.read}}`.{{/has}}
+{{#has tools "edit"}}- Surgical text edits → `{{toolRefs.edit}}`.{{/has}}
+{{#has tools "write"}}- File create/overwrite → `{{toolRefs.write}}`.{{/has}}
+{{#has tools "lsp"}}- Code intelligence → `{{toolRefs.lsp}}`.{{/has}}
+{{#has tools "search"}}- Regex search → `{{toolRefs.search}}`.{{/has}}
+{{#has tools "find"}}- File globbing → `{{toolRefs.find}}`.{{/has}}
 {{#has tools "eval"}}- Quick compute → `{{toolRefs.eval}}` when it improves correctness.{{/has}}
-{{#has tools "bash"}}- Shell → `{{toolRefs.bash}}` only for terminal operations that dedicated tools do not cover. Never use shell pipelines for reading, searching, globbing, or truncating output.{{/has}}
+{{#has tools "bash"}}- Shell → `{{toolRefs.bash}}` only for terminal operations that dedicated tools do not cover; never pipe to truncate output.{{/has}}
 </tool-priority>
 </tools>
 

package/src/prompts/tools/bash.md

@@ -40,12 +40,12 @@ Use it only for sanctioned GJC workflow CLI persistence or state read/write/cont
 
 <critical>
 {{#when restrictionProfile "==" "read-only"}}
-- Use read-only bash only for approved inspection commands that are materially better than `read`, `search`, or `find`; the tool itself blocks non-approved commands and unsafe shell shapes.
+- Use read-only bash only for approved inspection commands that are materially better than dedicated tools; unsafe shell shapes are blocked.
 {{else}}
-- NEVER use Linux coreutils (`cat`, `head`, `tail`, `less`, `more`, `ls`, `grep`, `rg`, `awk`, `sed`, `find`, `fd`, etc.) when a dedicated tool suffices — ALWAYS prefer `read`, `search`, `find`, `edit`, `write`.
+- Use bash only for terminal operations that dedicated tools do not cover.
 {{/when}}
-- NEVER pipe through `| head -n N` or `| tail -n N` — output is already truncated with the full result available via `artifact://<id>`.
-- NEVER redirect with `2>&1` or `2>/dev/null` — stdout and stderr are already merged.
+- Never pipe through `| head -n N` or `| tail -n N` — output is already truncated with the full result available via `artifact://<id>`.
+- Never redirect with `2>&1` or `2>/dev/null` — stdout and stderr are already merged.
 </critical>
 
 <output>

package/src/prompts/tools/browser.md

@@ -1,41 +1,22 @@
 Drives a real Chromium tab with full puppeteer access via JS execution.
 
 <instruction>
-- For static web content (articles, docs, issues/PRs, JSON, PDFs, feeds), prefer the `read` tool with a URL — reader-mode text without spinning up a browser. Use this tool when you need JS execution, authentication, or interactive actions.
+- For static web content (articles, docs, issues/PRs, JSON, PDFs, feeds), prefer the `read` tool with a URL. Use this tool only when you need JS execution, authentication, or interactive actions.
 - Four actions:
-  - `open` — acquire (or reuse) a named tab. `name` defaults to `"main"`. Optional `url` navigates after the tab is ready. Optional `viewport` sets dimensions. Optional `dialogs: "accept" | "dismiss"` auto-handles `alert`/`confirm`/`beforeunload` so navigation/clicks don't hang (default: leave dialogs unhandled — page hangs until caller wires `page.on('dialog', …)`).
-  - `close` — release a tab by `name`, or every tab with `all: true`. For spawned-app browsers, set `kill: true` to terminate the process tree (default leaves it running).
-  - `act` — run a list of structured `actions` against an existing tab without writing JS (preferred for routine navigation/interaction). Each step is `{ verb, … }`; verbs: `navigate {url, wait_until?}`, `click {id|selector}`, `type {id|selector, text}`, `fill {selector, value}`, `select {selector, values}`, `press {key, selector?}`, `scroll {dx?, dy?}`, `back`, `wait {selector?|ms?}`, `observe {viewport_only?, include_all?}`, `extract {format?}`, `screenshot`. Address elements by the numeric `id` from a prior `observe` (preferred) or a selector. Steps run in order; the tool returns an array of per-step results (observations/extracted content included). Use `run` only when a verb does not cover what you need.
-  - `run` — execute JS against an existing tab. `code` is the body of an async function with `page`, `browser`, `tab`, `display`, `assert`, `wait` in scope. The function's return value is JSON-stringified into the tool result; multiple `display(value)` calls accumulate text/images.
+  - `open` — acquire (or reuse) a named tab. `name` defaults to `"main"`. Optional `url`, `viewport`, and `dialogs: "accept" | "dismiss"` (auto-handles `alert`/`confirm`/`beforeunload`). The `app` field selects the browser kind (spawned binary, saved Chrome profile, or existing CDP endpoint); omitted means headless Chromium with stealth patches.
+  - `close` — release a tab by `name`, or every tab with `all: true`. `kill: true` also terminates a spawned-app process tree.
+  - `act` — run a list of structured `actions` against an existing tab without writing JS (preferred for routine navigation/interaction). Each step is `{ verb, … }`; verbs: `navigate {url, wait_until?}`, `click {id|selector}`, `type {id|selector, text}`, `fill {selector, value}`, `select {selector, values}`, `press {key, selector?}`, `scroll {dx?, dy?}`, `back`, `wait {selector?|ms?}`, `observe {viewport_only?, include_all?}`, `extract {format?}`, `screenshot`. Address elements by the numeric `id` from a prior `observe` (preferred) or a selector. Steps run in order; the tool returns per-step results.
+  - `run` — execute JS against an existing tab. `code` is the body of an async function with `page`, `browser`, `tab`, `display`, `assert`, `wait` in scope. The return value is JSON-stringified into the tool result; `display(value)` calls accumulate text/images. Use `run` only when an `act` verb does not cover what you need.
 - Tabs survive across `run` calls and across in-process subagents. Open once, reuse many times.
-- Browser kinds, selected by the `app` field on `open`:
-  - default (no `app`) → headless Chromium with stealth patches.
-  - `app.path` → spawn an absolute binary (Electron/CDP). If a running instance already exposes a CDP port, it is reused; otherwise stale instances are killed and a fresh one is spawned. Do not use this for a daily Chrome profile; use `app.browser: "chrome"` instead.
-  - `app.browser: "chrome"` + `app.path` + `app.user_data_dir` + `app.profile_directory` → use an existing saved Chrome profile. GJC binds CDP to `127.0.0.1` on an ephemeral or `app.cdp_port` port, reuses a matching running profile only when it already exposes attachable localhost CDP, refuses a matching non-CDP running profile instead of killing/relaunching it, and kills only the Chrome process GJC launched. Externally-owned CDP is disconnect-only. `app.background`/`app.no_focus` add Chromium's `--no-startup-window` guard; focus avoidance is best-effort and platform-dependent.
-  - `app.cdp_url` → connect to an existing CDP endpoint (e.g. `http://127.0.0.1:9222`). For logged-in profiles, only expose CDP on localhost and treat the endpoint as full browser-account access.
-  - `app.target` (with `path`/`cdp_url`/Chrome profile) — substring matched against url+title to pick a BrowserWindow when the app exposes several.
-- Inside `run`, `tab` exposes high-level helpers; reach for `page` (raw puppeteer Page) when you need anything they don't cover.
-  - `tab.goto(url, { waitUntil? })` — clears the element cache and navigates.
-  - `tab.observe({ includeAll?, viewportOnly? })` — accessibility snapshot. Returns `{ url, title, viewport, scroll, elements: [{ id, role, name, value, states, … }] }`. Element ids are stable until the next observe/goto.
-  - `tab.id(n)` — resolves an element id from the most recent observe to a real `ElementHandle` you can `.click()`, `.type()`, etc.
-  - `tab.click(selector)` / `tab.type(selector, text)` / `tab.fill(selector, value)` / `tab.press(key, { selector? })` / `tab.scroll(dx, dy)` — selector-based actions.
-  - `tab.waitFor(selector)` — waits until the selector is attached, returns the resolved `ElementHandle` for chaining (e.g. `const btn = await tab.waitFor('text/Submit'); await btn.click();`).
-  - `tab.drag(from, to)` — drag from one point to another. Each endpoint is either a selector string (drag center-to-center) or a `{ x, y }` viewport-coordinate point (e.g. for canvases, sliders).
-  - `tab.scrollIntoView(selector)` — scroll the matching element to the center of the viewport (use before clicking off-screen elements).
-  - `tab.select(selector, …values)` — set the selected option(s) on a `<select>`. Returns the values that ended up selected. `tab.fill` NEVER works for selects.
-  - `tab.uploadFile(selector, …filePaths)` — attach files to an `<input type="file">`. Paths resolve relative to cwd.
-  - `tab.waitForUrl(pattern, { timeout? })` — pattern is a substring or `RegExp`. Polls `location.href` so it works for SPA pushState navigations, not just real navigations. Returns the matched URL.
-  - `tab.waitForResponse(pattern, { timeout? })` — pattern is a substring, `RegExp`, or `(response) => boolean`. Returns the raw puppeteer `HTTPResponse` (call `.text()` / `.json()` / `.status()` / `.headers()` on it).
-  - `tab.evaluate(fn, …args)` — sugar for `page.evaluate` with the abort signal already wired. Use this instead of dropping to `page.evaluate` for ad-hoc DOM reads.
-  - `tab.screenshot({ selector?, fullPage?, save?, silent? })` — auto-attaches the image to the tool output unless `silent: true`. Saves full-res to `save` (or `browser.screenshotDir` setting) and a downscaled copy to the model.
-  - `tab.extract(format = "markdown")` — Readability-extracted page content.
-- Selectors accept CSS as well as puppeteer query handlers: `aria/Sign in`, `text/Continue`, `xpath/…`, `pierce/…`. Playwright-style `p-aria/[name="…"]`, `p-text/…`, etc. are normalized.
-- Default to `tab.observe()` over `tab.screenshot()` for understanding page state. Screenshot only when visual appearance matters.
+- Browser kinds: no `app` launches headless Chromium; `app.path` reuses CDP or kills stale same-path processes before spawning — NEVER use it for a daily Chrome profile; use explicit `app.browser: "chrome"` profile mode instead. Saved-profile/CDP automation has access to that profile's cookies and authenticated accounts. Profile mode refuses a matching non-CDP Chrome instead of killing/relaunching it, and `kill: true` can terminate only a Chrome process GJC launched; `app.cdp_url` is externally owned and disconnect-only. CDP must stay on `127.0.0.1`: it grants full browser-account access.
+- Inside `run`, `tab` exposes high-level helpers (`goto`, `observe`, `id`, `click`, `type`, `fill`, `press`, `waitFor`, `screenshot`, `extract`, …); reach for `page` (raw puppeteer Page) when they don't cover it.
+- Selectors accept CSS as well as puppeteer query handlers: `aria/Sign in`, `text/Continue`, `xpath/…`, `pierce/…`.
+- Full reference — helpers, browser kinds, CDP/security details, and more examples — read `gjc://tools/browser.md`.
 </instruction>
 
 <critical>
 - You MUST call `open` before `run` or `act`. Neither implicitly creates a tab.
-- You NEVER screenshot just to "see what's on the page" — `tab.observe()` returns structured data with element ids you can act on immediately.
+- You MUST observe before taking a screenshot to understand page state; screenshot only when visual appearance matters.
 - After a `tab.goto()` or any navigation, prior element ids from `tab.observe()` are invalidated. Re-observe before referencing them.
 - `code` runs with full Node access. Treat it as your code, not sandboxed code.
 </critical>
@@ -43,31 +24,13 @@ Drives a real Chromium tab with full puppeteer access via JS execution.
 <examples>
 # Open a tab and read structured page data
 `{"action":"open","name":"docs","url":"https://example.com"}`
-`{"action":"run","name":"docs","code":"const obs = await tab.observe(); display(obs); return obs.elements.length;"}`
+`{"action":"act","name":"docs","actions":[{"verb":"observe"}]}`
 
-# Click an observed element by id
-`{"action":"run","name":"docs","code":"const obs = await tab.observe(); const link = obs.elements.find(e => e.role === 'link' && e.name === 'Sign in'); assert(link, 'Sign in link missing'); await (await tab.id(link.id)).click();"}`
+# Click an observed element, then fill and submit a form
+`{"action":"act","name":"docs","actions":[{"verb":"click","id":12},{"verb":"fill","selector":"input[name=email]","value":"me@example.com"},{"verb":"click","selector":"text/Continue"}]}`
 
-# Save a full-page screenshot to disk
-`{"action":"run","name":"docs","code":"await tab.screenshot({ fullPage: true, save: 'screenshot.png' });"}`
-
-# Fill and submit a form via selectors
-`{"action":"run","name":"docs","code":"await tab.fill('input[name=email]', 'me@example.com'); await tab.click('text/Continue');"}`
-
-# Attach to an existing Electron app
-`{"action":"open","name":"cursor","app":{"path":"/Applications/Cursor.app/Contents/MacOS/Cursor"}}`
-
-# Use an existing Chrome profile in the background
-`{"action":"open","name":"work-browser","app":{"browser":"chrome","path":"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome","user_data_dir":"~/Library/Application Support/Google/Chrome","profile_directory":"Profile 10","background":true,"no_focus":true,"target":"example.com"}}`
-
-# Close one tab (browser stays alive if other tabs reference it)
-`{"action":"close","name":"docs"}`
-
-# Close every tab; leave spawned apps running
-`{"action":"close","all":true}`
-
-# Close every tab and kill spawned-app processes too
-`{"action":"close","all":true,"kill":true}`
+# Use `run` only when `act` has no suitable verb
+`{"action":"run","name":"docs","code":"const count = await page.locator('canvas').count(); return { count };"}`
 </examples>
 
 <output>

package/src/prompts/tools/find.md

@@ -29,6 +29,6 @@ For open-ended searches requiring multiple rounds of globbing and searching, del
 </avoid>
 
 <critical>
-- You MUST use the built-in Find tool for every file-name lookup. NEVER shell out to `find`, `fd`, `locate`, `ls`, or `git ls-files` via Bash — they ignore `.gitignore`, blow past result limits, and waste tokens.
-- If you catch yourself typing `find -name`, `fd`, or `ls **/*.ext` in a Bash command, stop and re-issue the lookup through the Find tool with a glob pattern instead.
+- Use separate array entries for multiple path globs.
+- Set `gitignore: false` only when ignored files are intentionally in scope.
 </critical>

package/src/prompts/tools/hashline.md

@@ -20,11 +20,13 @@ Each op line is ONE of:
 - Payload ends at the next `»`, `«`, `≔`, `§`, envelope marker, or EOF.
 - `≔A..B` with no payload deletes the range. To keep a blank line, include one explicit empty payload line.
 - **Payload is only what's NEW relative to your range:**
-  - `≔` replaces inside; NEVER include lines outside.
+  - `≔` replaces inside; NEVER include lines outside or replay past B — extend B if it must go.
   - `»`/`«` adds at the anchor; NEVER repeat line A or neighbors.
   - Payload matching nearby content duplicates — drop it or widen.
-- **Pick a self-contained unit first.** Touching a multiline construct? Widen to the whole thing.
+- **Pick a self-contained unit first.** Touching a multiline construct? Widen to the whole thing; narrow beats wide otherwise.
 - Then smallest op: add → `»`/`«`; delete/replace → `≔`.
+- **Anchors reference the file as last read.** NEVER shift for prior ops, fabricate hashes, or anchor outside the visible region — re-`read` first.
+- **One `»`/`«` op per block, NOT per line.** N lines = ONE op, N payloads. Collapse adjacent ops.
 </rules>
 
 <brace-shapes>
@@ -35,16 +37,6 @@ When braces bound your edit, you SHOULD prefer these shapes:
 - **End on `}`**: only when that `}` is part of the change. Otherwise extend or stop earlier.
 </brace-shapes>
 
-<common-failures>
-- **NEVER replay past your range.** Stop before B+1; extend B if it must go.
-- **NEVER duplicate chunks inside one payload.** Caught re-emitting? Rewrite.
-- **Anchor only inside the visible region.** B+1 truncated? Re-`read` first.
-- **You SHOULD prefer the narrowest self-contained edit.** Narrow range beats wide range.
-- **Anchors reference the file as last read.** NEVER shift for prior ops.
-- **One `»`/`«` op per block, NOT per line.** N lines = ONE op, N payloads. Collapse adjacent ops.
-- **NEVER fabricate anchor hashes.** Missing? Re-`read`.
-</common-failures>
-
 <case file="mod.ts">
 {{hline 1 "const TITLE = \"Mr\";"}}
 {{hline 2 "export function greet(name) {"}}
@@ -69,56 +61,22 @@ const TITLE = "Mrs";
 		name?.trim() || "guest",
 	].join(" ");
 
-# Insert AFTER/BEFORE a line
-§mod.ts
-»{{hrefr 4}}
+# Insert after / before a line
+`§mod.ts`
+`»{{hrefr 4}}`
 		"Dr",
-«{{hrefr 5}}
+`«{{hrefr 5}}`
 		"Dr",
 
-# Append to file
-§mod.ts
-»EOF
-export const done = true;
-
 # Delete a line
-§mod.ts
-≔{{hrefr 5}}
-
-# Blank a line (replace with LF: the empty payload is the blank line before `»EOF`)
-§mod.ts
-≔{{hrefr 5}}
+`§mod.ts`
+`≔{{hrefr 5}}`
 
-»EOF
-export const done = true;
+# Replace with one blank line: the empty payload line follows the operation
+`§mod.ts`
+`≔{{hrefr 5}}`
 </examples>
 
-<anti-pattern>
-# WRONG — replaces 2 lines just to add one.
-§mod.ts
-≔{{hrefr 1}}..{{hrefr 2}}
-const TITLE = "Mr";
-const DEBUG = false;
-export function greet(name) {
-# RIGHT — same effect, one-line insert
-§mod.ts
-»{{hrefr 1}}
-const DEBUG = false;
-
-# WRONG — replace from the middle of a larger statement (error-prone)
-§mod.ts
-≔{{hrefr 4}}..{{hrefr 5}}
-		"Dr",
-		name?.trim() || "guest",
-# RIGHT — widen to the full statement
-§mod.ts
-≔{{hrefr 3}}..{{hrefr 6}}
-	return [
-		"Dr",
-		name?.trim() || "guest",
-	].join(" ");
-</anti-pattern>
-
 <critical>
 - Copy anchors verbatim (line number + 2-char hash); NEVER include the `|TEXT` body.
 - NEVER write unified diff syntax. Headers are `§PATH`; ops are `»`/`«`/`≔`.

package/src/prompts/tools/read.md

@@ -73,10 +73,7 @@ For `.sqlite`, `.sqlite3`, `.db`, `.db3`:
 `agent://<id>`, `artifact://<id>`, `rule://<name>`, and `local://<name>.md` resolve transparently and accept the same line selectors as filesystem paths. Use `artifact://<id>` to recover full output that a previous bash/eval/tool result spilled or truncated.
 
 <critical>
-- You MUST use `read` for every file, directory, archive, and URL inspection. `cat`, `head`, `tail`, `less`, `more`, `ls`, `tar`, `unzip`, `curl`, `wget` are FORBIDDEN — any such bash call is a bug, regardless of how short or convenient it looks.
-- You MUST prefer `read` over a browser/puppeteer tool for URL content; only reach for a browser when `read` cannot deliver reasonable content.
-- You MUST always include `path`. NEVER call `read` with `{}`.
-- For line ranges, append the selector to `path` (`path="src/foo.ts:50-200"`, `path="src/foo.ts:50+150"`). NEVER substitute `sed -n`, `awk NR`, or `head`/`tail` pipelines.
-- Summary footer says `read <path>:raw …`? Re-issue the exact selector it names. NEVER guess what's inside `..` / `…` markers — they carry no content.
-- You MAY combine selectors with URL reads and internal URIs; both paginate the cached resolved output.
+- Always include `path`; never call `read` with `{}`.
+- For line ranges, append the selector to `path`.
+- Re-issue the selector named by a summary footer before relying on elided content.
 </critical>

package/src/prompts/tools/search-tool-bm25.md

@@ -1,8 +1,6 @@
 Search hidden tool metadata to discover and activate tools.
 
 Activate hidden tools (MCP and built-in) when you need a capability not in your active tool set.
-{{#if hasDiscoverableMCPServers}}Discoverable MCP servers in this session: {{#list discoverableMCPServerSummaries join=", "}}{{this}}{{/list}}.{{/if}}
-{{#if discoverableMCPToolCount}}Total discoverable tools available: {{discoverableMCPToolCount}}.{{/if}}
 Input:
 - `query` — required natural-language or keyword query
 - `limit` — optional maximum number of tools to return and activate (default `8`; start with 5–10 if unsure)

package/src/prompts/tools/search.md

@@ -18,8 +18,6 @@ Searches files using powerful regex matching.
 </output>
 
 <critical>
-- You MUST use the built-in `search` tool for any content search. NEVER shell out to `grep`, `rg`, `ripgrep`, `ag`, `ack`, `git grep`, `awk`, `sed`-for-search, or any other CLI search via Bash — even for a single match, even "just to check quickly", even piped through other commands.
-- Bash `grep`/`rg` loses `.gitignore` semantics, bypasses result limits, and wastes tokens. The `search` tool is faster, structured, and already wired into the workspace — there is no scenario where Bash search is preferable.
-- If you catch yourself typing `grep`, `rg`, or `| grep` in a Bash command, stop and re-issue the lookup through the `search` tool instead.
-- If the search is open-ended and requires multiple rounds across subsystems, delegate a bounded fact-finding task to an appropriate canonical role agent (`planner` for sequencing/context maps or `architect` for read-only architecture assessment) instead of chaining broad `search` calls yourself.
+- Search paths are an array; pass separate entries rather than comma-joined paths.
+- Use a cross-line pattern only when the match actually spans lines.
 </critical>

package/src/prompts/tools/skill-discovery.md

@@ -1,8 +1,7 @@
 Discover project and user runtime skills without loading full skill content.
 
 <instruction>
-- Searches only custom runtime skill locations: project `.gjc/skills` and user `~/.gjc/skills`.
-- Built-in, bundled, and internal workflow skills are intentionally excluded.
+- Searches only custom runtime skill locations: nearest project `.gjc/skills`; then, under the home directory, canonical `<config>/agent/skills`, configured legacy `<config>/skills`, and historical legacy `.gjc/skills`. `<config>` is the home-relative directory name from `GJC_CONFIG_DIR`, then `PI_CONFIG_DIR`, then `.gjc`; even an absolute-looking configured name is joined beneath `<home>`. Duplicate names use that exact precedence. Built-in, bundled, and internal workflow skills are intentionally excluded.
 - Returns thin metadata only: name, description, source scope, path, and use conditions when present.
 - To load a selected skill's full `SKILL.md`, invoke it through the existing `skill` tool with the exact `name` returned here.
 </instruction>

package/src/prompts/tools/task.md

@@ -7,7 +7,7 @@ Launches subagents to parallelize workflows.
 {{else}}
 - Use `subagent` action `inspect` or `list` to snapshot manager state.
 {{/if}}
-- To wait or cancel, use the `subagent` tool; its await/cancel doctrine applies (never cancel just because an await timed out).
+- To wait or cancel, use the `subagent` tool; its await/cancel doctrine is authoritative.
 
 {{#if ircEnabled}}
 Subagents have no conversation history, but they can reach you and their siblings live via the `irc` tool. Front-load every fact, file path, and direction they need in {{#if contextEnabled}}`context` or `assignment`{{else}}each `assignment`{{/if}}.

package/src/runtime-mcp/manager.ts

@@ -1424,7 +1424,7 @@ export class MCPManager {
 	}
 
 	/**
-	 * Get all server instructions (for system prompt injection).
+	 * Get connected-server instructions for request-scoped untrusted user-role context.
 	 */
 	getServerInstructions(): Map<string, string> {
 		if (this.#toolsOnly) return new Map();