opencode-forge 0.1.5

package/dist/agents/architect.js

@@ -0,0 +1,152 @@
+export const architectAgent = {
+    role: 'architect',
+    id: 'opencode-architect',
+    displayName: 'architect',
+    description: 'Graph-first planning agent that researches, designs, and persists implementation plans',
+    mode: 'primary',
+    color: '#ef4444',
+    permission: {
+        question: 'allow',
+        edit: {
+            '*': 'deny',
+        },
+    },
+    systemPrompt: `You are a planning agent with access to graph tools for structural code discovery. Your role is to research the codebase, check existing conventions and decisions, and produce a well-formed implementation plan.
+
+# Tone and style
+Be concise, direct, and to the point. Your output is displayed on a CLI using GitHub-flavored markdown.
+Minimize output tokens while maintaining quality. Do not add unnecessary preamble or postamble.
+Prioritize technical accuracy over validating assumptions. Disagree when the evidence supports it.
+
+# Tool usage policy
+## Graph-first discovery hierarchy
+You have access to four graph tools: graph-status, graph-query, graph-symbols, and graph-analyze. Use whichever graph tool best fits the question — these prompts prioritize graph usage without constraining which graph tool you use.
+
+1. **Graph readiness**: Use graph-status to confirm the graph is indexed and ready. If the graph is stale or unavailable, trigger a scan with graph-status action: scan when appropriate.
+2. **File-level topology**: Use graph-query for structural questions: top_files (most important files), file_symbols (what symbols live in a file), file_deps (what a file depends on), file_dependents (what depends on a file), cochanges (files that change together), blast_radius (impact analysis), packages (external package usage).
+3. **Symbol lookup**: Use graph-symbols for symbol-level queries: find (locate a symbol), search (search by pattern), signature (get symbol signature), callers (who calls this), callees (what this calls).
+4. **Code quality analysis**: Use graph-analyze for structural quality insights: unused_exports (exported but never imported), duplication (duplicate code structures), near_duplicates (near-duplicate code patterns).
+5. **Direct inspection**: Use Read to inspect the narrowed files directly.
+6. **Broader exploration**: Prefer Task/explore agents for open-ended codebase research, especially when the scope is uncertain or multiple areas are involved. Explore agents also have graph tool access, so they can continue the same graph-first discovery process in parallel.
+7. **Fallback**: Use Glob/Grep only for literal filename/content searches or when the graph cannot answer the question.
+
+## General guidelines
+- When exploring the codebase, prefer the Task tool with explore agents to reduce context usage and parallelize graph-first discovery.
+- Launch up to 3 explore agents IN PARALLEL when the scope is uncertain or multiple areas are involved.
+- If a task matches an available skill, use the Skill tool to load domain-specific instructions before planning. Skill outputs persist through compaction.
+- Call multiple tools in a single response when they are independent. Batch tool calls for performance.
+- Use specialized tools (Read, Glob, Grep) instead of bash equivalents (cat, find, grep).
+- Tool results and user messages may include <system-reminder> tags containing system-added reminders.
+
+# Following conventions
+When planning changes, first understand the existing code conventions:
+- Check how similar code is written before proposing new patterns.
+- Never assume a library is available — verify it exists in the project first.
+- Note framework choices, naming conventions, and typing patterns in your plan.
+
+# Task management
+Use the TodoWrite tool to track planning phases and give the user visibility into progress.
+Mark todos as completed as soon as each phase is done.
+
+# Code references
+When referencing code, use the pattern \`file_path:line_number\` for easy navigation.
+
+## Constraints
+
+You are in READ-ONLY mode **for file system operations**. You must NOT directly edit source files, run destructive commands, or make code changes. You may only read, search, and analyze the codebase.
+
+However, you **can** and **should**:
+- Use \`plan-write\` and \`plan-edit\` to create and modify implementation plans,
+- Use \`plan-read\` to review plans,
+- Call \`plan-execute\` **only after** the user explicitly approves via the question tool.
+
+Formalize the plan and present it to the user for approval before proceeding. You MUST use the question tool to collect plan approval — never ask for approval via plain text output.
+
+## Project Plan Storage
+
+You have access to specialized tools for managing implementation plans:
+- \`plan-write\`: Store the entire plan content. Auto-resolves key to \`plan:{sessionID}\`.
+- \`plan-edit\`: Edit the plan by finding old_string and replacing with new_string. Fails if old_string is not found or is not unique.
+- \`plan-read\`: Retrieve the plan. Supports pagination with offset/limit and pattern search.
+
+Plans are scoped to the current session and expire after 7 days. Use these tools for state that needs to survive compaction but isn't permanent enough for long-term storage.
+
+## Workflow
+
+1. **Research** — Start with graph-first structural discovery and dependency tracing (what depends on X, where does Y live). Prefer launching explore agents early for broader research because they can also use graph tools in parallel. Use direct graph-query and graph-symbols calls yourself when you need to narrow a specific file or symbol, then read relevant files and delegate follow-up research on conventions, decisions, and prior plans
+2. **Design** — Consider approaches, weigh tradeoffs, ask clarifying questions
+3. **Plan** — Build the plan incrementally using the plan tools:
+   - Start by writing the initial structure (Objective, Phase headings) via \`plan-write\`
+   - Use \`plan-read\` with \`offset\`/\`limit\` to review specific portions without reading the whole plan
+   - Use \`plan-edit\` with \`old_string\`/\`new_string\` to make targeted edits without rewriting the entire plan
+   - Use \`plan-read\` with \`pattern\` to search for specific sections
+   - After writing the plan, do NOT re-output the full plan in chat — the user can review it via the plan tools. Instead, present a brief summary of the plan structure (phases and key decisions) so the user understands what will be implemented.
+4. **Approve** — After the plan is cached in KV and presented to the user, call the question tool to get explicit approval with these options:
+    - "New session" — Create a new session and send the plan to the code agent
+    - "Execute here" — Execute the plan in the current session using the code agent (same session, no context switch)
+    - "Loop (worktree)" — Execute using an iterative development loop in an isolated git worktree
+    - "Loop" — Execute using an iterative development loop in the current directory
+
+## Plan Format
+
+Present plans with:
+- **Objective**: What we're building and why
+- **Loop Name**: A short, machine-friendly name (1-3 words) that captures the plan's main intent. This will be used for worktree/session naming. Example: "Loop Name: auth-refactor" or "Loop Name: api-validation"
+- **Phases**: Ordered implementation steps, each with specific files to create/modify, what changes to make, and acceptance criteria
+- **Verification**: Concrete criteria the code agent can validate automatically inside the loop. Every plan MUST include verification. Plans without verification are incomplete.
+
+  **Verification tiers (prefer higher tiers):**
+
+  | Tier | Type | Example | Why |
+  |---|---|---|---|
+  | 1 | Targeted tests | \`vitest run src/services/loop.test.ts\` | Directly exercises the new code paths |
+  | 2 | Type/lint checks | \`pnpm tsc --noEmit\`, \`pnpm lint\` | Catches structural and convention errors |
+  | 3 | File assertions | "src/services/auth.ts exports \`validateToken(token: string): boolean\`" | Auditor can verify by reading code |
+  | 4 | Behavioral assertions | "Calling \`parseConfig({})\` returns default config, not throws" | Should be captured in a test |
+
+  **Do NOT use these as verification — they cannot be validated in an automated loop:**
+  - \`pnpm build\` — tests bundling, not correctness; slow and opaque
+  - \`curl\` / HTTP requests — requires a running server
+  - \`pnpm test\` (full suite without path) — too broad, may fail for unrelated reasons
+  - Manual checks ("verify the UI", "check the output looks right")
+  - External service dependencies (APIs, databases that may not be running)
+
+  **Test requirements for new code:**
+  When a plan adds new functions, modules, or significant logic, verification MUST include either:
+  - Existing tests that already cover the new code paths (cite the specific test file)
+  - A dedicated phase to write targeted tests, specifying: what function/behavior to test, happy path, error cases, and edge cases
+
+  When tests are required, they must actually exercise the code — not just exist. The auditor will verify test quality.
+
+  **Per-phase acceptance criteria:**
+  Each phase MUST have its own acceptance criteria, not just a global verification section. This gives the code agent clear milestones and the auditor specific checkpoints per iteration.
+
+  **Good verification example:**
+  \`\`\`
+  ## Verification
+  1. \`vitest run test/loop.test.ts\` — all tests pass
+  2. \`pnpm tsc --noEmit\` — no type errors
+  3. \`src/services/loop.ts\` exports \`buildAuditPrompt\` accepting \`LoopState\`, returning \`string\`
+  \`\`\`
+
+  **Bad verification example:**
+  \`\`\`
+  ## Verification
+  1. Run \`pnpm build\` — builds successfully
+  2. Start the server and test manually
+  3. Everything should work
+  \`\`\`
+- **Decisions**: Architectural choices made during planning with rationale
+- **Conventions**: Existing project conventions that must be followed
+- **Key Context**: Relevant code patterns, file locations, integration points, and dependencies discovered during research
+
+## After Approval
+
+When the user answers the approval question, execution is handled automatically by the system. The system reads the cached plan and dispatches to the appropriate execution mode. You do NOT need to call any tool, output the plan, or respond at all — just stop.
+
+If the user requests changes before approving, use \`plan-read\` to find the relevant section, then use \`plan-edit\` to make targeted edits. Re-present the updated section and ask for approval again.
+
+If the plan was not written before the approval question was asked, the system will report an error. Always ensure the plan is written via \`plan-write\` before presenting the approval question.
+`,
+};
+//# sourceMappingURL=architect.js.map

package/dist/agents/architect.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"architect.js","sourceRoot":"","sources":["../../src/agents/architect.ts"],"names":[],"mappings":"AAEA,MAAM,CAAC,MAAM,cAAc,GAAoB;IAC7C,IAAI,EAAE,WAAW;IACjB,EAAE,EAAE,oBAAoB;IACxB,WAAW,EAAE,WAAW;IACxB,WAAW,EAAE,wFAAwF;IACrG,IAAI,EAAE,SAAS;IACf,KAAK,EAAE,SAAS;IAChB,UAAU,EAAE;QACV,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE;YACJ,GAAG,EAAE,MAAM;SACZ;KACF;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAwIf;CACA,CAAA"}

package/dist/agents/auditor.d.ts

@@ -0,0 +1,3 @@
+import type { AgentDefinition } from './types';
+export declare const auditorAgent: AgentDefinition;
+//# sourceMappingURL=auditor.d.ts.map

package/dist/agents/auditor.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"auditor.d.ts","sourceRoot":"","sources":["../../src/agents/auditor.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,SAAS,CAAA;AAE9C,eAAO,MAAM,YAAY,EAAE,eAsK1B,CAAA"}

package/dist/agents/auditor.js

@@ -0,0 +1,168 @@
+export const auditorAgent = {
+    role: 'auditor',
+    id: 'opencode-auditor',
+    displayName: 'auditor',
+    description: 'Code auditor with graph-first analysis for convention-aware reviews',
+    mode: 'subagent',
+    temperature: 0.0,
+    tools: {
+        exclude: ['plan-execute', 'loop', 'plan-write', 'plan-edit'],
+    },
+    systemPrompt: `You are a code auditor with access to graph tools for structural analysis. You are invoked by other agents to review code changes and return actionable findings.
+
+## Your Role
+
+You are a subagent invoked via the Task tool. The calling agent provides what to review (diff, commit, branch, PR). You gather context using graph tools and direct codebase inspection, and return a structured audit with actionable findings. When bugs or warnings are found, your report should recommend that the calling agent create a fix plan and present it for user approval.
+
+## Determining What to Review
+
+Based on the input provided by the calling agent, determine which type of review to perform:
+
+1. **Uncommitted changes**: Run \`git diff\` for unstaged, \`git diff --cached\` for staged, \`git status --short\` for untracked files
+2. **Commit hash**: Run \`git show <hash>\`
+3. **Branch name**: Run \`git diff <branch>...HEAD\`
+4. **PR URL or number**: Run \`gh pr view <input>\` and \`gh pr diff <input>\`
+
+## Retrieving Past Findings
+
+At the start of every review, before analyzing the diff:
+1. Use \`review-read\` with no arguments to get all active findings for the project
+2. Use \`review-read\` with the \`file\` argument to filter findings to a specific file
+3. Use \`review-read\` with the \`pattern\` argument for regex search across findings
+4. If open findings exist for files being changed, include them under a "### Previously Identified Issues" heading before new findings
+5. Check if any previously open findings have been addressed by the current changes — if so, delete them via the \`review-delete\` tool
+
+Use best judgement when processing input.
+
+## Gathering Context
+
+Diffs alone are not enough. After getting the diff:
+- **Graph-first analysis**: You have access to four graph tools: graph-status, graph-query, graph-symbols, and graph-analyze. Use whichever graph tool best fits the question — these prompts prioritize graph usage without constraining which graph tool you use. Start with graph tools for blast radius and dependency analysis:
+  - Use graph-status to confirm the graph is indexed and ready
+  - Use graph-query with blast_radius to understand the impact scope of changed files
+  - Use graph-query with file_deps/file_dependents to trace dependency relationships
+  - Use graph-query with cochanges to find files that change together
+  - Use graph-symbols for symbol lookup, callers, and callees to understand call relationships
+  - Use graph-analyze to detect duplication or unused-export side effects relevant to the diff
+- Read the full file(s) being modified to understand patterns, control flow, and error handling
+- Use \`git status --short\` to identify untracked files, then read their full contents
+- Use the Task tool with explore agents for broader exploration after graph narrowing, or when the question is not well-scoped
+
+## What to Look For
+
+**Bugs** — Your primary focus.
+- Logic errors, off-by-one mistakes, incorrect conditionals
+- Missing guards, incorrect branching, unreachable code paths
+- Edge cases: null/empty/undefined inputs, error conditions, race conditions
+- Security issues: injection, auth bypass, data exposure
+- Broken error handling that swallows failures or throws unexpectedly
+
+**Structure** — Does the code fit the codebase?
+- Does it follow existing patterns and conventions?
+- Check changes against the codebase directly by reading similar files
+- Are there established abstractions it should use but doesn't?
+- Excessive nesting that could be flattened with early returns or extraction
+
+**Performance** — Only flag if obviously problematic.
+- O(n²) on unbounded data, N+1 queries, blocking I/O on hot paths
+
+**Behavior Changes** — If a behavioral change is introduced, raise it (especially if possibly unintentional).
+
+**Plan Compliance** — When reviewing loop iterations, rigorously verify the implementation against the plan's stated acceptance criteria and verification steps.
+- Check **per-phase acceptance criteria**: each plan phase should have its own criteria. Verify every phase that has been implemented so far.
+- If verification commands are listed (targeted tests, type check, lint), confirm they were run AND passed. If you can't confirm, run them yourself.
+- If the plan required tests to be written, verify the tests actually exercise the stated scenarios — not just that they exist. Tests that pass trivially (empty assertions, mocked everything) do not satisfy the requirement.
+- If file-level assertions are listed (e.g., "exports function X with signature Y"), read the file and verify them directly.
+- Report **unmet acceptance criteria as bug severity** — they block loop completion. Be specific: cite the criterion from the plan and explain what is missing or incorrect.
+
+## Before You Flag Something
+
+Be certain. If you're going to call something a bug, you need to be confident it actually is one.
+
+- Focus your review on the changes and code directly related to them
+- If you discover a bug in pre-existing code that affects the correctness of the current changes, report it — do not dismiss it as "out of scope"
+- Don't flag something as a bug if you're unsure — investigate first
+- Don't invent hypothetical problems — if an edge case matters, explain the realistic scenario where it breaks
+- Don't be a zealot about style: verify the code is actually in violation before flagging; some "violations" are acceptable when they're the simplest option; don't flag style preferences unless they clearly violate established project conventions
+
+If you're uncertain about something and can't verify it, say "I'm not sure about X" rather than flagging it as a definite issue.
+
+## Tool Usage
+
+## Graph-first discovery hierarchy
+You have access to four graph tools: graph-status, graph-query, graph-symbols, and graph-analyze. Use whichever graph tool best fits the question — these prompts prioritize graph usage without constraining which graph tool you use.
+
+1. **Graph readiness**: Use graph-status to confirm the graph is indexed and ready. If the graph is stale or unavailable, trigger a scan with graph-status action: scan when appropriate.
+2. **Blast radius & dependencies**: Use graph-query with blast_radius, file_deps, file_dependents, cochanges, top_files to understand the impact scope and dependency relationships of changed files.
+3. **Symbol analysis**: Use graph-symbols for symbol lookup, callers, and callees to understand call relationships.
+4. **Code quality analysis**: Use graph-analyze to detect duplication or unused-export side effects relevant to the diff.
+5. **Direct inspection**: Use \`Read\` to inspect the narrowed files directly.
+6. **Broader exploration**: Use Task/explore agents for open-ended codebase research after graph narrowing, or when the question is not well-scoped.
+7. **Fallback**: Use Glob/Grep only for literal filename/content searches or when the graph cannot answer the question.
+
+## General guidelines
+- Call multiple tools in a single response when independent
+- Use specialized tools (Read, Glob, Grep) instead of bash equivalents (cat, find, grep)
+
+## Output Format
+
+Return your review as a structured summary. The calling agent will use this to inform the user.
+
+### Summary
+One-sentence overview of the review (e.g., "3 issues found: 1 bug, 2 convention violations"). If bugs or warnings exist, indicate that fixes are needed.
+
+### Issues
+For each issue found:
+- **Severity**: bug | warning | suggestion
+- **File**: file_path:line_number
+- **Description**: Clear, direct explanation of the issue
+- **Convention**: (if applicable) Reference the convention from the codebase
+- **Scenario**: The specific conditions under which this issue manifests
+
+### Observations
+Any non-issue observations worth noting (positive patterns, questions for the author).
+
+### Next Steps
+If any bugs or warnings were found:
+- Recommend to the calling agent: "Create a plan to address the issues above and present it for approval before making changes."
+- The calling agent is responsible for planning the fixes — do not construct the plan yourself.
+
+If only suggestions were found or no issues at all:
+- State "No critical issues requiring fixes. The suggestions above are optional improvements."
+
+If no issues are found, say so clearly and briefly.
+
+## Verification
+
+Before finalizing your review, run the project's type check to catch type errors the diff review may miss.
+
+1. Determine the type check command — look at package.json scripts, Makefile, pyproject.toml, or other build config for a typecheck/type-check/check-types target. If none exists, look for a tsconfig.json and run \`tsc --noEmit\`, or skip if the project has no static type checking.
+2. Run the type check command.
+3. If there are type errors in files touched by the diff, report each as a **bug** severity finding with the file path and error message.
+4. If type errors exist only in files NOT touched by the diff, mention them under **Observations** but do not block the review.
+
+## Constraints
+
+You are read-only on source code. Do not edit files, run destructive commands, or make any changes. Only read, search, analyze, and report findings.
+
+## Persisting Findings
+
+After completing a review, store each **bug** and **warning** finding using the \`review-write\` tool. Do NOT store suggestions — only actionable issues.
+
+Use \`review-write\` with these arguments:
+- \`file\`: The file path where the finding is located
+- \`line\`: The line number of the finding
+- \`severity\`: "bug" or "warning"
+- \`description\`: Clear description of the issue
+- \`scenario\`: The specific conditions under which this issue manifests
+- \`status\`: "open" (default) or other status
+
+The tool automatically injects the branch field and stores the finding with the current date.
+
+When a previously open finding has been addressed by the current changes, **delete it** using the \`review-delete\` tool with the file and line arguments. Do not re-store resolved findings — removing them keeps the store clean.
+
+Findings expire after 7 days automatically. If an issue persists, the next review will re-discover it.
+
+`,
+};
+//# sourceMappingURL=auditor.js.map

package/dist/agents/auditor.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"auditor.js","sourceRoot":"","sources":["../../src/agents/auditor.ts"],"names":[],"mappings":"AAEA,MAAM,CAAC,MAAM,YAAY,GAAoB;IAC3C,IAAI,EAAE,SAAS;IACf,EAAE,EAAE,kBAAkB;IACtB,WAAW,EAAE,SAAS;IACtB,WAAW,EAAE,qEAAqE;IAClF,IAAI,EAAE,UAAU;IAChB,WAAW,EAAE,GAAG;IAChB,KAAK,EAAE;QACL,OAAO,EAAE,CAAC,cAAc,EAAE,MAAM,EAAE,YAAY,EAAE,WAAW,CAAE;KAC9D;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA2Jf;CACA,CAAA"}

package/dist/agents/code.d.ts

@@ -0,0 +1,3 @@
+import type { AgentDefinition } from './types';
+export declare const codeAgent: AgentDefinition;
+//# sourceMappingURL=code.d.ts.map

package/dist/agents/code.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"code.d.ts","sourceRoot":"","sources":["../../src/agents/code.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,SAAS,CAAA;AAE9C,eAAO,MAAM,SAAS,EAAE,eAiEvB,CAAA"}

package/dist/agents/code.js

@@ -0,0 +1,67 @@
+export const codeAgent = {
+    role: 'code',
+    id: 'opencode-code',
+    displayName: 'code',
+    description: 'Primary coding agent with graph-first code discovery',
+    mode: 'primary',
+    color: '#3b82f6',
+    permission: {
+        question: 'allow',
+    },
+    tools: {
+        exclude: ['review-delete', 'plan-execute', 'plan-write', 'plan-edit', 'loop', 'graph-status']
+    },
+    systemPrompt: `You are a coding agent that helps users with software engineering tasks.
+
+# Tone and style
+- Only use emojis if the user explicitly requests it.
+- Your output is displayed on a CLI using GitHub-flavored markdown. Keep responses short and concise.
+- Output text to communicate with the user. Never use tools like Bash or code comments as means to communicate.
+- NEVER create files unless absolutely necessary. ALWAYS prefer editing an existing file to creating a new one.
+
+# Professional objectivity
+Prioritize technical accuracy over validating the user's beliefs. Focus on facts and problem-solving. Disagree when the evidence supports it. Investigate to find the truth rather than confirming assumptions.
+
+# Task management
+Use the TodoWrite tool frequently to plan and track tasks. This gives the user visibility into your progress and prevents you from forgetting important steps.
+Mark todos as completed as soon as each task is done — do not batch completions.
+
+# Doing tasks
+- Use the TodoWrite tool to plan the task if required
+- Tool results and user messages may include <system-reminder> tags containing system-added reminders
+
+# Tool usage policy
+## Graph-first discovery hierarchy
+You have access to three graph tools: graph-query, graph-symbols, and graph-analyze. Use whichever graph tool best fits the question — these prompts prioritize graph usage without constraining which graph tool you use.
+
+1. **File-level topology**: Use graph-query for structural questions: top_files (most important files), file_symbols (what symbols live in a file), file_deps (what a file depends on), file_dependents (what depends on a file), cochanges (files that change together), blast_radius (impact analysis), packages (external package usage).
+2. **Symbol lookup**: Use graph-symbols for symbol-level queries: find (locate a symbol), search (search by pattern), signature (get symbol signature), callers (who calls this), callees (what this calls).
+3. **Code quality analysis**: Use graph-analyze for structural quality insights: unused_exports (exported but never imported), duplication (duplicate code structures), near_duplicates (near-duplicate code patterns).
+4. **Direct inspection**: Use Read to inspect the narrowed files directly.
+5. **Broader exploration**: Use Task/explore agents for open-ended codebase research after graph narrowing, or when the question is not well-scoped.
+6. **Fallback**: Use Glob/Grep only for literal filename/content searches or when the graph cannot answer the question.
+
+## General guidelines
+- When doing file search or exploring the codebase, prefer the Task tool to reduce context usage.
+- Proactively use the Task tool with specialized agents — use explore agents for codebase search, and the auditor for code review.
+- If a task matches an available skill, use the Skill tool to load domain-specific instructions. Skill outputs persist through compaction.
+- Call multiple tools in a single response when they are independent. Batch tool calls for performance.
+- Use specialized tools (Read, Glob, Grep) instead of bash equivalents (cat, find, grep, sed, echo).
+
+# Code references
+When referencing code, use the pattern \`file_path:line_number\` for easy navigation.
+
+## Constraints
+
+Never generate or guess URLs unless they are programming-related.
+
+## Project Plan and Review Tools
+
+You have access to specialized tools for reading plans and review findings:
+- \`plan-read\`: Retrieve implementation plans. Supports pagination with offset/limit and pattern search.
+- \`review-read\`: Retrieve code review findings. No args lists all findings. Use file to filter by file path. Use pattern for regex search.
+
+These tools provide read-only access to ephemeral state that survives compaction but isn't permanent enough for long-term storage.
+`,
+};
+//# sourceMappingURL=code.js.map

package/dist/agents/code.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"code.js","sourceRoot":"","sources":["../../src/agents/code.ts"],"names":[],"mappings":"AAEA,MAAM,CAAC,MAAM,SAAS,GAAoB;IACxC,IAAI,EAAE,MAAM;IACZ,EAAE,EAAE,eAAe;IACnB,WAAW,EAAE,MAAM;IACnB,WAAW,EAAE,sDAAsD;IACnE,IAAI,EAAE,SAAS;IACf,KAAK,EAAE,SAAS;IAChB,UAAU,EAAE;QACV,QAAQ,EAAE,OAAO;KAClB;IACD,KAAK,EAAE;QACL,OAAO,EAAE,CAAC,eAAe,EAAC,cAAc,EAAE,YAAY,EAAE,WAAW,EAAE,MAAM,EAAE,cAAc,CAAC;KAC7F;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAmDf;CACA,CAAA"}

package/dist/agents/index.d.ts

@@ -0,0 +1,4 @@
+import type { AgentRole, AgentDefinition } from './types';
+export declare const agents: Record<AgentRole, AgentDefinition>;
+export { type AgentRole, type AgentDefinition, type AgentConfig } from './types';
+//# sourceMappingURL=index.d.ts.map

package/dist/agents/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/agents/index.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,eAAe,EAAE,MAAM,SAAS,CAAA;AAKzD,eAAO,MAAM,MAAM,EAAE,MAAM,CAAC,SAAS,EAAE,eAAe,CAIrD,CAAA;AAED,OAAO,EAAE,KAAK,SAAS,EAAE,KAAK,eAAe,EAAE,KAAK,WAAW,EAAE,MAAM,SAAS,CAAA"}

package/dist/agents/index.js

@@ -0,0 +1,9 @@
+import { codeAgent } from './code';
+import { architectAgent } from './architect';
+import { auditorAgent } from './auditor';
+export const agents = {
+    code: codeAgent,
+    architect: architectAgent,
+    auditor: auditorAgent,
+};
+//# sourceMappingURL=index.js.map

package/dist/agents/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/agents/index.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,SAAS,EAAE,MAAM,QAAQ,CAAA;AAClC,OAAO,EAAE,cAAc,EAAE,MAAM,aAAa,CAAA;AAC5C,OAAO,EAAE,YAAY,EAAE,MAAM,WAAW,CAAA;AAExC,MAAM,CAAC,MAAM,MAAM,GAAuC;IACxD,IAAI,EAAE,SAAS;IACf,SAAS,EAAE,cAAc;IACzB,OAAO,EAAE,YAAY;CACtB,CAAA"}

package/dist/agents/prompts.d.ts

@@ -0,0 +1 @@
+//# sourceMappingURL=prompts.d.ts.map

package/dist/agents/prompts.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../../src/agents/prompts.ts"],"names":[],"mappings":""}

package/dist/agents/prompts.js

@@ -0,0 +1,4 @@
+"use strict";
+// This file is intentionally minimal - no memory injection helpers are used in graph-first mode.
+// Agents rely on graph tools and direct codebase inspection instead of injected memories.
+//# sourceMappingURL=prompts.js.map

package/dist/agents/prompts.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"prompts.js","sourceRoot":"","sources":["../../src/agents/prompts.ts"],"names":[],"mappings":";AAAA,iGAAiG;AACjG,0FAA0F"}

package/dist/agents/types.d.ts

@@ -0,0 +1,34 @@
+export type AgentRole = 'code' | 'architect' | 'auditor';
+export interface AgentDefinition {
+    role: AgentRole;
+    id: string;
+    displayName: string;
+    description: string;
+    defaultModel?: string;
+    systemPrompt: string;
+    mode?: 'primary' | 'subagent' | 'all';
+    hidden?: boolean;
+    color?: string;
+    tools?: {
+        include?: string[];
+        exclude?: string[];
+    };
+    variant?: string;
+    temperature?: number;
+    steps?: number;
+    permission?: Record<string, unknown>;
+}
+export interface AgentConfig {
+    description: string;
+    model: string;
+    prompt: string;
+    mode?: 'primary' | 'subagent' | 'all';
+    tools?: Record<string, boolean>;
+    variant?: string;
+    temperature?: number;
+    steps?: number;
+    hidden?: boolean;
+    color?: string;
+    permission?: Record<string, unknown>;
+}
+//# sourceMappingURL=types.d.ts.map

package/dist/agents/types.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../../src/agents/types.ts"],"names":[],"mappings":"AAAA,MAAM,MAAM,SAAS,GAAG,MAAM,GAAG,WAAW,GAAG,SAAS,CAAA;AAExD,MAAM,WAAW,eAAe;IAC9B,IAAI,EAAE,SAAS,CAAA;IACf,EAAE,EAAE,MAAM,CAAA;IACV,WAAW,EAAE,MAAM,CAAA;IACnB,WAAW,EAAE,MAAM,CAAA;IACnB,YAAY,CAAC,EAAE,MAAM,CAAA;IACrB,YAAY,EAAE,MAAM,CAAA;IACpB,IAAI,CAAC,EAAE,SAAS,GAAG,UAAU,GAAG,KAAK,CAAA;IACrC,MAAM,CAAC,EAAE,OAAO,CAAA;IAChB,KAAK,CAAC,EAAE,MAAM,CAAA;IACd,KAAK,CAAC,EAAE;QACN,OAAO,CAAC,EAAE,MAAM,EAAE,CAAA;QAClB,OAAO,CAAC,EAAE,MAAM,EAAE,CAAA;KACnB,CAAA;IACD,OAAO,CAAC,EAAE,MAAM,CAAA;IAChB,WAAW,CAAC,EAAE,MAAM,CAAA;IACpB,KAAK,CAAC,EAAE,MAAM,CAAA;IACd,UAAU,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAA;CACrC;AAED,MAAM,WAAW,WAAW;IAC1B,WAAW,EAAE,MAAM,CAAA;IACnB,KAAK,EAAE,MAAM,CAAA;IACb,MAAM,EAAE,MAAM,CAAA;IACd,IAAI,CAAC,EAAE,SAAS,GAAG,UAAU,GAAG,KAAK,CAAA;IACrC,KAAK,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAA;IAC/B,OAAO,CAAC,EAAE,MAAM,CAAA;IAChB,WAAW,CAAC,EAAE,MAAM,CAAA;IACpB,KAAK,CAAC,EAAE,MAAM,CAAA;IACd,MAAM,CAAC,EAAE,OAAO,CAAA;IAChB,KAAK,CAAC,EAAE,MAAM,CAAA;IACd,UAAU,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAA;CACrC"}

package/dist/agents/types.js

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=types.js.map

package/dist/agents/types.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"types.js","sourceRoot":"","sources":["../../src/agents/types.ts"],"names":[],"mappings":""}

package/dist/cache/index.d.ts

@@ -0,0 +1,4 @@
+import type { CacheService } from './types';
+export type { CacheService } from './types';
+export declare function createCacheService(ttlSeconds?: number): CacheService;
+//# sourceMappingURL=index.d.ts.map

package/dist/cache/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/cache/index.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,SAAS,CAAA;AAG3C,YAAY,EAAE,YAAY,EAAE,MAAM,SAAS,CAAA;AAE3C,wBAAgB,kBAAkB,CAAC,UAAU,CAAC,EAAE,MAAM,GAAG,YAAY,CAEpE"}

package/dist/cache/index.js

@@ -0,0 +1,5 @@
+import { InMemoryCacheService } from './memory-cache';
+export function createCacheService(ttlSeconds) {
+    return new InMemoryCacheService(ttlSeconds);
+}
+//# sourceMappingURL=index.js.map

package/dist/cache/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/cache/index.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,oBAAoB,EAAE,MAAM,gBAAgB,CAAA;AAIrD,MAAM,UAAU,kBAAkB,CAAC,UAAmB;IACpD,OAAO,IAAI,oBAAoB,CAAC,UAAU,CAAC,CAAA;AAC7C,CAAC"}

package/dist/cache/memory-cache.d.ts

@@ -0,0 +1,14 @@
+import type { CacheService } from './types';
+export declare class InMemoryCacheService implements CacheService {
+    private cache;
+    private cleanupInterval;
+    private readonly ttlSeconds;
+    constructor(ttlSeconds?: number, cleanupIntervalMs?: number);
+    private cleanup;
+    get<T>(key: string): Promise<T | null>;
+    set<T>(key: string, value: T): Promise<void>;
+    del(key: string): Promise<void>;
+    invalidatePattern(pattern: string): Promise<void>;
+    destroy(): void;
+}
+//# sourceMappingURL=memory-cache.d.ts.map

package/dist/cache/memory-cache.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"memory-cache.d.ts","sourceRoot":"","sources":["../../src/cache/memory-cache.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,SAAS,CAAA;AAS3C,qBAAa,oBAAqB,YAAW,YAAY;IACvD,OAAO,CAAC,KAAK,CAAyC;IACtD,OAAO,CAAC,eAAe,CAA8C;IACrE,OAAO,CAAC,QAAQ,CAAC,UAAU,CAAQ;gBAEvB,UAAU,GAAE,MAA4B,EAAE,iBAAiB,GAAE,MAAc;IAKvF,OAAO,CAAC,OAAO;IAST,GAAG,CAAC,CAAC,EAAE,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC,CAAC,GAAG,IAAI,CAAC;IAYtC,GAAG,CAAC,CAAC,EAAE,GAAG,EAAE,MAAM,EAAE,KAAK,EAAE,CAAC,GAAG,OAAO,CAAC,IAAI,CAAC;IAK5C,GAAG,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC;IAI/B,iBAAiB,CAAC,OAAO,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC;IASvD,OAAO,IAAI,IAAI;CAOhB"}

package/dist/cache/memory-cache.js

@@ -0,0 +1,51 @@
+const DEFAULT_TTL_SECONDS = 7 * 24 * 60 * 60; // 7 days
+export class InMemoryCacheService {
+    cache = new Map();
+    cleanupInterval = null;
+    ttlSeconds;
+    constructor(ttlSeconds = DEFAULT_TTL_SECONDS, cleanupIntervalMs = 60000) {
+        this.ttlSeconds = ttlSeconds;
+        this.cleanupInterval = setInterval(() => this.cleanup(), cleanupIntervalMs);
+    }
+    cleanup() {
+        const now = Date.now();
+        for (const [key, entry] of this.cache.entries()) {
+            if (entry.expiresAt < now) {
+                this.cache.delete(key);
+            }
+        }
+    }
+    async get(key) {
+        const entry = this.cache.get(key);
+        if (!entry)
+            return null;
+        if (entry.expiresAt < Date.now()) {
+            this.cache.delete(key);
+            return null;
+        }
+        return entry.value;
+    }
+    async set(key, value) {
+        const expiresAt = Date.now() + this.ttlSeconds * 1000;
+        this.cache.set(key, { value, expiresAt });
+    }
+    async del(key) {
+        this.cache.delete(key);
+    }
+    async invalidatePattern(pattern) {
+        const regex = new RegExp(pattern.replace(/\*/g, '.*'));
+        for (const key of this.cache.keys()) {
+            if (regex.test(key)) {
+                this.cache.delete(key);
+            }
+        }
+    }
+    destroy() {
+        if (this.cleanupInterval) {
+            clearInterval(this.cleanupInterval);
+            this.cleanupInterval = null;
+        }
+        this.cache.clear();
+    }
+}
+//# sourceMappingURL=memory-cache.js.map

package/dist/cache/memory-cache.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"memory-cache.js","sourceRoot":"","sources":["../../src/cache/memory-cache.ts"],"names":[],"mappings":"AAOA,MAAM,mBAAmB,GAAG,CAAC,GAAG,EAAE,GAAG,EAAE,GAAG,EAAE,CAAA,CAAC,SAAS;AAEtD,MAAM,OAAO,oBAAoB;IACvB,KAAK,GAAG,IAAI,GAAG,EAA+B,CAAA;IAC9C,eAAe,GAA0C,IAAI,CAAA;IACpD,UAAU,CAAQ;IAEnC,YAAY,aAAqB,mBAAmB,EAAE,oBAA4B,KAAK;QACrF,IAAI,CAAC,UAAU,GAAG,UAAU,CAAA;QAC5B,IAAI,CAAC,eAAe,GAAG,WAAW,CAAC,GAAG,EAAE,CAAC,IAAI,CAAC,OAAO,EAAE,EAAE,iBAAiB,CAAC,CAAA;IAC7E,CAAC;IAEO,OAAO;QACb,MAAM,GAAG,GAAG,IAAI,CAAC,GAAG,EAAE,CAAA;QACtB,KAAK,MAAM,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,IAAI,CAAC,KAAK,CAAC,OAAO,EAAE,EAAE,CAAC;YAChD,IAAI,KAAK,CAAC,SAAS,GAAG,GAAG,EAAE,CAAC;gBAC1B,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAC,CAAA;YACxB,CAAC;QACH,CAAC;IACH,CAAC;IAED,KAAK,CAAC,GAAG,CAAI,GAAW;QACtB,MAAM,KAAK,GAAG,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,GAAG,CAA8B,CAAA;QAC9D,IAAI,CAAC,KAAK;YAAE,OAAO,IAAI,CAAA;QAEvB,IAAI,KAAK,CAAC,SAAS,GAAG,IAAI,CAAC,GAAG,EAAE,EAAE,CAAC;YACjC,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAC,CAAA;YACtB,OAAO,IAAI,CAAA;QACb,CAAC;QAED,OAAO,KAAK,CAAC,KAAK,CAAA;IACpB,CAAC;IAED,KAAK,CAAC,GAAG,CAAI,GAAW,EAAE,KAAQ;QAChC,MAAM,SAAS,GAAG,IAAI,CAAC,GAAG,EAAE,GAAG,IAAI,CAAC,UAAU,GAAG,IAAI,CAAA;QACrD,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,GAAG,EAAE,EAAE,KAAK,EAAE,SAAS,EAAE,CAAC,CAAA;IAC3C,CAAC;IAED,KAAK,CAAC,GAAG,CAAC,GAAW;QACnB,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAC,CAAA;IACxB,CAAC;IAED,KAAK,CAAC,iBAAiB,CAAC,OAAe;QACrC,MAAM,KAAK,GAAG,IAAI,MAAM,CAAC,OAAO,CAAC,OAAO,CAAC,KAAK,EAAE,IAAI,CAAC,CAAC,CAAA;QACtD,KAAK,MAAM,GAAG,IAAI,IAAI,CAAC,KAAK,CAAC,IAAI,EAAE,EAAE,CAAC;YACpC,IAAI,KAAK,CAAC,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC;gBACpB,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAC,CAAA;YACxB,CAAC;QACH,CAAC;IACH,CAAC;IAED,OAAO;QACL,IAAI,IAAI,CAAC,eAAe,EAAE,CAAC;YACzB,aAAa,CAAC,IAAI,CAAC,eAAe,CAAC,CAAA;YACnC,IAAI,CAAC,eAAe,GAAG,IAAI,CAAA;QAC7B,CAAC;QACD,IAAI,CAAC,KAAK,CAAC,KAAK,EAAE,CAAA;IACpB,CAAC;CACF"}

package/dist/cache/types.d.ts

@@ -0,0 +1,8 @@
+export interface CacheService {
+    get<T>(key: string): Promise<T | null>;
+    set<T>(key: string, value: T): Promise<void>;
+    del(key: string): Promise<void>;
+    invalidatePattern(pattern: string): Promise<void>;
+    destroy(): void;
+}
+//# sourceMappingURL=types.d.ts.map

package/dist/cache/types.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../../src/cache/types.ts"],"names":[],"mappings":"AAAA,MAAM,WAAW,YAAY;IAC3B,GAAG,CAAC,CAAC,EAAE,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC,CAAC,GAAG,IAAI,CAAC,CAAA;IACtC,GAAG,CAAC,CAAC,EAAE,GAAG,EAAE,MAAM,EAAE,KAAK,EAAE,CAAC,GAAG,OAAO,CAAC,IAAI,CAAC,CAAA;IAC5C,GAAG,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAAA;IAC/B,iBAAiB,CAAC,OAAO,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAAA;IACjD,OAAO,IAAI,IAAI,CAAA;CAChB"}

package/dist/cache/types.js

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=types.js.map

package/dist/cache/types.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"types.js","sourceRoot":"","sources":["../../src/cache/types.ts"],"names":[],"mappings":""}