changes

.config/opencode/commands/bootstrap-memory.md

@@ -1,98 +0,0 @@
----
-title: bootstrap-memory
-type: note
-permalink: opencode-config/commands/bootstrap-memory
----
-
-# Bootstrap Project Memory
-
-RUN { git ls-files; git ls-files --others --exclude-standard; } 2>/dev/null | sort -u
-READ README.md
-
-You are bootstrapping basic-memory project notes for this project.
-
-Your job is to inspect the codebase and create an initial knowledge baseline in
-basic-memory. Capture architecture, core modules, conventions, and key decisions
-so future sessions can resume quickly.
-
-## Step 0: Ensure a dedicated per-repo basic-memory project exists
-
-Use `list_memory_projects` to check whether this repo already has a basic-memory
-project. If not, create one with `create_memory_project` using a short kebab-case
-name (e.g., `my-web-app`) and the repo's `.memory/` subdirectory as `project_path`
-(e.g., `/path/to/repo/.memory`).
-
-All subsequent `write_note`, `search_notes`, and `build_context` calls in this
-command must pass `project="<repo-project-name>"` for project-specific notes, or
-`project="main"` for cross-project reusable knowledge.
-
-## Step 1: Check existing basic-memory state
-
-Use `search_notes` and `build_context` (with `project="<repo-project-name>"`) to
-check whether this project already has notes in basic-memory. Understanding
-current state prevents duplication and helps you decide what to create vs update.
-
-## Step 2: Inspect project structure
-
-Run `git ls-files` to understand the project layout, then read `README.md` and
-the highest-signal files for architecture and conventions.
-
-Also check whether any legacy tool-specific instruction files exist alongside
-`AGENTS.md` — they may contain project knowledge from other tools or team
-members that should be consolidated into `AGENTS.md`.
-
-Identify:
-- What the project does (primary capabilities)
-- Core modules/subsystems and responsibilities
-- Key patterns/conventions (naming, layering, testing, config)
-
-## Step 3: Write initial knowledge notes
-
-Use `write_note` (with `project="<repo-project-name>"`) to create project
-knowledge notes under the `knowledge/` folder:
-- Project purpose and scope
-- Architecture overview
-- Key modules with file paths
-- Important implementation patterns/conventions
-
-## Step 4: Seed decisions notes
-
-Use `write_note` (with `project="<repo-project-name>"`) to create a `decisions/`
-note with any clear, durable decisions found in docs or code patterns (for
-example: stack choices, testing strategy, architectural constraints). Include
-rationale when known.
-
-## Step 5: Initialize plans/research notes
-
-- If active in-progress work is discoverable, use `write_note` (with
-  `project="<repo-project-name>"`) to create a `plans/<feature>` note with scope,
-  tasks, and acceptance criteria.
-- If research artifacts are discovered, use `write_note` (with
-  `project="<repo-project-name>"`) to create a `research/<topic>` note with
-  findings and references.
-
-## Step 6: Record cross-project reusable knowledge
-
-If you discover patterns, conventions, or tech knowledge that would benefit other
-projects, use `write_note` with `project="main"` to record them as global notes.
-Do not store project-specific plans, decisions, or session state in `main`.
-
-## Step 7: Update instruction file
-
-If `AGENTS.md` exists, update it with any new project knowledge discovered
-during bootstrap (architecture, conventions, commands). Add the repo's
-basic-memory project name (e.g., `opencode-config`) to `AGENTS.md` so
-agents know which project to target. If legacy tool-specific instruction files
-exist, consolidate any durable repo guidance into `AGENTS.md` and stop
-maintaining duplicate copies.
-
-If the instruction file doesn't exist, note that `/init` should be run to create it.
-
-## Guidelines
-
-- Be specific with file paths, APIs, parameters, and behavioral details.
-- Keep sections concise and scannable.
-- Prefer durable knowledge over transient status notes.
-- Use WikiLinks `[[Topic]]` to create relations between related notes.
-- Use tags for categorization: `#pattern`, `#convention`, `#decision`, `#architecture`.
-- Always pass the `project` parameter on every MCP call.

.config/opencode/commands/build.md

@@ -0,0 +1,15 @@
+---
+description: Execute the latest approved plan
+agent: builder
+model: github-copilot/gpt-5.4
+---
+
+Execute the latest approved plan for: $ARGUMENTS
+
+1. Read the latest matching `plans/<slug>` note with `Status: approved`.
+2. Create or update `executions/<slug>` with `Status: in_progress` before changing code.
+3. Delegate implementation to `coder`, verification to `tester`, review to `reviewer`, and docs or memory updates to `librarian` where appropriate.
+4. Follow the plan exactly. If the plan is contradictory, missing a dependency, or fails verification twice, stop, capture evidence, set the execution note to blocked, and send the work back to `planner`.
+5. Finish by updating the execution note to `Status: done` or `Status: blocked` and summarizing what changed.
+
+Do not create a commit unless the user explicitly asks.

.config/opencode/commands/continue.md

@@ -0,0 +1,12 @@
+---
+description: Resume unfinished planner or builder workflow from memory
+model: github-copilot/gpt-5.4
+---
+
+Continue the highest-priority unfinished work for this repository.
+
+1. Inspect basic-memory for incomplete work under `plans/`, `executions/`, `findings/`, and `decisions/`.
+2. If the current primary agent is `planner`, resume the most relevant plan that is `Status: draft` or `Status: blocked` and drive it toward an approved spec.
+3. If the current primary agent is `builder`, resume the most relevant execution note that is `Status: in_progress` or `Status: blocked`. If there is no approved plan, stop and hand the work back to `planner`.
+4. Refresh the open findings ledger and update note statuses as you work.
+5. Return the resumed slug, current status, next checkpoint, and any blocker.

.config/opencode/commands/docs.md

@@ -1,21 +0,0 @@
----
-description: Documentation coverage workflow using librarian subagent
-agent: librarian
-subtask: true
-permalink: opencode-config/commands/docs
----
-
-Review the implemented change set and ensure required documentation coverage is complete.
-
-Change set scope:
-$ARGUMENTS
-
-Requirements:
-
-- Read relevant basic-memory project notes first for prior workflow and documentation decisions (use `project="<repo-project-name>"`).
-- If scope is ambiguous, ask one focused clarification question using the question tool.
-- Update required documentation surfaces:
-  - `README`
-  - relevant `docs/*`
-  - `AGENTS.md` when workflow, policy, or agent behavior changes.
-- Report what changed, what remains (if anything), and any explicitly deferred documentation debt.

.config/opencode/commands/init.md

@@ -1,109 +1,15 @@
 ---
-description: Initialize or update a project with scaffold, docs, and basic-memory
-  notes — adapts to both new and existing projects.
-permalink: opencode-config/commands/init
+description: Initialize or refresh project memory and AGENTS.md
+agent: builder
+model: github-copilot/gpt-5.4
 ---
 
-You are initializing or updating a project. Follow these steps in order.
+Initialize this repository for the planner/builder workflow.
 
-Project hint (may be empty):
-$ARGUMENTS
+1. Verify that a dedicated per-repo basic-memory project exists for the current repository. If it does not, create it at `<repo-root>/.memory` using a short kebab-case project name.
+2. Gather high-signal project context in parallel: purpose, stack, architecture, entrypoints, build/test commands, coding conventions, and major risks.
+3. Write or refresh project memory notes under `project/overview`, `project/architecture`, `project/workflows`, and `project/testing`.
+4. Use `librarian` to create or update the project-root `AGENTS.md` so it matches the repository and documents the important working agreements.
+5. Record any missing information or open findings under `findings/` instead of guessing.
 
-## Step 1 — Explore current project state (delegate to `explorer`)
-
-Delegate to the `explorer` subagent first, before any questions, to determine whether this is a new or existing project.
-
-- Ask explorer to inspect the working tree for project-defining artifacts, including:
-  - source files and source directories
-  - `README.md`, `AGENTS.md`, `docs/`
-  - stack markers such as `package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `composer.json`
-  - git markers such as `.git/`
-  - any similar files that strongly indicate an existing project
-- Ask explorer to return:
-  - classification: `new_project` or `existing_project`
-  - inferred project name, purpose, and tech stack (with confidence)
-  - which required scaffold files already exist vs are missing
-  - whether `.git/` exists
-
-## Step 2 — Clarify (Lead, one round max)
-
-Use the `question` tool for at most one round, adapting to Step 1 findings.
-
-- If explorer's classification confidence is low (e.g., directory has only a few ambiguous files), include the classification itself as a question to confirm.
-- If classification is `existing_project`:
-  - confirm or correct explorer inferences (name, one-sentence purpose, stack)
-  - ask only for unknown or low-confidence fields
-  - do **not** ask whether to initialize git if `.git/` already exists
-  - do **not** ask for files/details that are already present and clear
-- If classification is `new_project`:
-  - ask:
-    - project name and one-sentence purpose
-    - primary language / framework / tech stack
-    - whether to initialize a git repository
-
-## Step 3 — Scaffold (delegate to `coder`)
-
-Delegate to the `coder` subagent with explicit mode (`new_project` or `existing_project`) and the file existence map from Step 1.
-
-- Required scaffold targets:
-  - `README.md` — title, purpose, tech stack, quick-start, project structure overview
-  - `AGENTS.md` — instruction file containing shared project guidance
-  - `docs/architecture.md` — stub with title + purpose
-  - `.gitignore` — add stack-appropriate ignores (e.g., `node_modules/`, `__pycache__/`, `target/`)
-  - other stack-specific scaffold files if clearly implied (e.g., `package.json`, `pyproject.toml`)
-- If `new_project`:
-  - create all required scaffold files/directories
-- If `existing_project`:
-  - create or fill in only missing pieces
-  - **do not overwrite existing files**
-  - explicitly instruct coder to check existence before creating each target
-  - ensure `AGENTS.md` exists as the project instruction file
-  - if legacy tool-specific instruction files exist, consolidate any repo-specific guidance into `AGENTS.md` and stop maintaining duplicate copies
-  - examples:
-    - if `docs/` is missing, create it and add `docs/architecture.md`
-
-## Step 4 — Documentation review (delegate to `librarian`)
-
-Always delegate to the `librarian` subagent, for both new and existing projects.
-
-- Ensure `README.md` is accurate and complete for the current project state.
-- Ensure `AGENTS.md` exists and captures project-specific workflow decisions from Step 2.
-- Ensure repo instruction guidance lives in `AGENTS.md` only.
-- Ensure stubs are explicitly marked for later completion.
-- Keep edits additive and non-destructive for existing projects.
-
-## Step 5 — Initialize or update basic-memory project notes (Lead)
-
-Always create or update basic-memory project notes for this project.
-
-- **Ensure a dedicated per-repo basic-memory project exists.** Use `list_memory_projects` to check. If not found, create one with `create_memory_project` using a short kebab-case name (e.g., `my-web-app`) and the repo's `.memory/` subdirectory as `project_path` (e.g., `/path/to/repo/.memory`).
-- All subsequent note operations in this step must pass `project="<repo-project-name>"`.
-- Use `search_notes` (with `project`) to check for existing project notes to avoid duplicates.
-- Use `write_note` (with `project`) to create or update a `knowledge/overview` note with:
-  - Project name
-  - Purpose and stack
-  - Key files (`README.md`, `AGENTS.md`, `docs/architecture.md` when present)
-  - Notable init/update decisions
-- Add WikiLink cross-references to related notes (e.g., `[[decisions/...]]`).
-
-## Step 6 — Git handling (delegate to `coder`)
-
-Delegate git operations to `coder` based on discovered state.
-
-- If `.git/` already exists:
-  - skip `git init`
-  - stage only newly created or modified files from this init/update flow
-  - create a commit
-- If `.git/` does not exist:
-  - use Step 2 answer to decide whether to run `git init`
-  - if initialized, stage only newly created or modified files and create a commit
-- Commit message should be concise and conventional, e.g.:
-  - `chore: initialize project scaffold` (new project)
-  - `chore: add missing project scaffolding` (existing project)
-
-## Completion report
-
-Summarize:
-- Files created and files updated, with purpose.
-- Decisions made and decisions deferred.
-- What the user should fill in next (stubs, open questions, follow-up documentation).
+Keep the output concise and actionable.

.config/opencode/commands/plan.md

@@ -1,29 +1,15 @@
 ---
-description: Trigger phased planning for a new task — enters CLARIFY mode and walks
-  through DISCOVER → PLAN → CRITIC-GATE
-permalink: opencode-config/commands/plan
+description: Produce or refresh an execution-ready plan
+agent: planner
+model: github-copilot/gpt-5.4
 ---
 
-You are the lead agent. The user has invoked `/plan` to begin structured planning for a task.
+Create or update an execution-ready plan for: $ARGUMENTS
 
-## Steps
+1. Gather the required repo and external context in parallel.
+2. Use `researcher`, `explorer`, and `reviewer` as needed.
+3. Write the canonical plan to basic-memory under `plans/<slug>`.
+4. Include: objective, scope, assumptions, constraints, task breakdown, parallel lanes, verification oracle, risks, and open findings.
+5. Set `Status: approved` only when `builder` can execute the plan without guesswork. Otherwise leave it blocked and explain why.
 
-1. **CLARIFY**: Ask the user clarifying questions about the task using the `question` tool. Gather: goals, constraints, affected areas, success criteria. Record in the relevant plan note (per-repo basic-memory project `plans/`).
-
-2. **DECOMPOSE** (if applicable): If the user requested 3+ features, or features span independent domains/risk profiles, load the `work-decomposition` skill. Follow its decomposition procedure to:
-   - Identify distinct features and assess independence
-   - Group into independent workstreams
-   - Classify risk profiles and assign quality tiers
-   - Allocate worktrees (one per independent workstream)
-   - Identify human checkpoint triggers (security, architecture, vision-dependent features)
-   - Present the decomposition to the user and wait for approval before proceeding
-
-3. **DISCOVER**: Delegate to `explorer` to map relevant parts of the codebase. Delegate to `researcher` for any technical unknowns. Record findings in per-repo basic-memory project notes (`research/` or `knowledge/`). Record reusable cross-project findings in `main`.
-
-4. **CONSULT** (if needed): For domain-specific questions, check per-repo project `decisions/` notes and `main` for cached SME guidance first. If not cached, delegate to `sme`.
-
-5. **PLAN**: Draft a phased task list per workstream. Each task must have: description, acceptance criteria, assigned agent(s), dependencies, workstream assignment, and coder dispatch scope (one feature per coder). Store the plan in the per-repo basic-memory project `plans/<feature>` note.
-
-6. **CRITIC-GATE**: Delegate plan to `critic`. If APPROVED → present plan to user and await go-ahead. If REPHRASE → revise and re-gate. If RESOLVE → **stop**, resolve every blocker, then re-gate. Do not proceed to EXECUTE with unresolved blockers.
-
-Present the final approved plan to the user before starting EXECUTE.
+Return the plan slug and the key execution checkpoints.

.config/opencode/commands/research.md

@@ -1,18 +0,0 @@
----
-description: Deep research workflow using researcher subagent
-agent: researcher
-subtask: true
-permalink: opencode-config/commands/research
----
-
-Research the following topic deeply and return a concise, evidence-backed report.
-
-Topic:
-$ARGUMENTS
-
-Requirements:
-
-- Read relevant basic-memory notes first (`search_notes` with `project="<repo-project-name>"`) for existing related research and decisions. Also check `project="main"` for cross-project guidance.
-- If scope is ambiguous, ask one focused clarification question using the question tool.
-- Provide findings, tradeoffs, and recommended approach.
-- Record durable project-specific insights in per-repo project notes (`write_note` with `project="<repo-project-name>"`). Record cross-project reusable insights with `project="main"`. Use tags and WikiLink cross-references.

.config/opencode/commands/review.md

@@ -1,18 +0,0 @@
----
-description: Code review workflow using reviewer subagent
-agent: reviewer
-subtask: true
-permalink: opencode-config/commands/review
----
-
-Review the requested scope and provide actionable feedback.
-
-Scope:
-$ARGUMENTS
-
-Requirements:
-
-- Read relevant basic-memory project notes first for project conventions and prior decisions (use `project="<repo-project-name>"`).
-- If review scope is ambiguous, ask one focused clarification question using the question tool.
-- Categorize findings: critical, warning, suggestion.
-- Include concrete file references and rationale.

.config/opencode/commands/save-memory.md

@@ -1,84 +0,0 @@
----
-title: save-memory
-type: note
-permalink: opencode-config/commands/save-memory
----
-
-# Save Session Knowledge
-
-You are saving what you learned this session into basic-memory notes.
-This is YOUR memory — record anything valuable for future sessions: what you
-understood about the project, what you built, decisions that were made, patterns
-you noticed, or intent the user shared.
-
-## Step 1: Identify the per-repo basic-memory project
-
-Use `list_memory_projects` to find this repo's dedicated basic-memory project.
-If it doesn't exist, create one with `create_memory_project` using a short
-kebab-case name and the repo's `.memory/` subdirectory as `project_path`
-(e.g., `/path/to/repo/.memory`).
-
-All project-specific notes must target `project="<repo-project-name>"`.
-Cross-project reusable knowledge must target `project="main"`.
-
-## Step 2: Load existing notes
-
-Use `search_notes` and `build_context` (with the correct `project`) to see
-what's already recorded. Understanding current state prevents duplication and
-helps you decide what to update.
-
-## Step 3: Reflect on this session
-
-Think about what happened this session. Consider:
-- What did you learn about the project's purpose or intent?
-- What features, modules, or components did you build or change?
-- What design or architectural decisions were made and why?
-- What patterns or conventions did you discover?
-- What research findings are worth keeping?
-- Did anything get removed, replaced, or deprecated?
-
-## Step 4: Map learnings to notes (with correct project target)
-
-For each thing worth remembering, write or update the right note in the right project:
-
-- **Project architecture/patterns/conventions** → per-repo project `knowledge/` notes (`project="<repo-project-name>"`)
-- **Decisions and rationale** → per-repo project `decisions/` notes (`project="<repo-project-name>"`)
-- **Ongoing feature plans and acceptance criteria** → per-repo project `plans/<feature>` notes (`project="<repo-project-name>"`)
-- **Deep research findings** → per-repo project `research/<topic>` notes (`project="<repo-project-name>"`)
-- **Reusable cross-project patterns, conventions, tech knowledge, lessons learned** → `project="main"` with appropriate tags
-
-**Hard rule:** Never store project-specific plans, decisions, research, gates, or sessions in `main`. Never store cross-project reusable knowledge in a per-repo project.
-
-Prefer updating existing notes over creating duplicates.
-
-## Step 5: Write updates
-
-Use `write_note` with appropriate folder, tags, WikiLinks, and **always the correct `project` parameter**.
-
-When writing, be specific:
-- include parameter names, defaults, file paths, behavior details
-- include rationale (`why`) for decisions
-- include WikiLink cross-references to related notes
-
-## Step 6: Verify and report
-
-Use `search_notes` (with `project`) to confirm notes reflect current understanding.
-Report what was added/updated, where, and in which project.
-
-## Step 7: Update instruction file if project knowledge changed
-
-If project `knowledge/` notes were **materially** updated (architecture, conventions,
-commands — not just plans/research), update `AGENTS.md` to reflect the changes.
-Keep repo instruction guidance in `AGENTS.md` only.
-
-If updates were only plans/research/tracking details, skip this step.
-
-## Guidelines
-
-- Record what a future you (with no memory of this session) would need to know.
-- Outcomes and rationale are more valuable than ceremony.
-- Don't log process-only updates like "started phase X".
-- Keep hierarchy shallow (max 2 heading levels preferred).
-- Be specific. "Handles auth" is weak. "JWT auth with RS256, validated in
-  `src/middleware/auth.ts`, refresh tokens in Redis with 7d TTL" is useful.
-- Always pass the `project` parameter on every MCP call.

.config/opencode/commands/sme.md

@@ -1,24 +0,0 @@
----
-description: Invoke the SME (Subject Matter Expert) agent for deep domain consultation
-  — guidance is cached in basic-memory project decisions notes
-permalink: opencode-config/commands/sme
----
-
-You are the lead agent. The user has invoked `/sme` to consult a domain expert.
-
-## Steps
-
-1. Check the per-repo basic-memory project's `decisions/` notes (`search_notes` with `project="<repo-project-name>"`) for existing SME guidance on the requested domain. Also check `project="main"` for cross-project cached guidance. If found, return the cached guidance immediately.
-
-2. If not cached, delegate to the `sme` agent with:
-   - The user's specific question
-   - Relevant context (project stack, constraints, current approach)
-   - Any relevant file paths or code snippets
-   - The per-repo basic-memory project name for project-specific caching
-
-3. Once SME responds, record or update the guidance:
-   - Project-specific guidance → `write_note` with `project="<repo-project-name>"` under `decisions/`
-   - Reusable cross-project guidance → `write_note` with `project="main"` with domain tags
-   Present the guidance to the user.
-
-4. Add WikiLink cross-references between the SME guidance note and any active plan notes.

.config/opencode/commands/status.md

@@ -1,20 +0,0 @@
----
-description: Show persistent cross-session work status from basic-memory project notes
-agent: lead
-permalink: opencode-config/commands/status
----
-
-Load persistent project status from basic-memory and provide a resume-oriented status report.
-
-Requirements:
-
-- Identify the per-repo basic-memory project for this repo (use `list_memory_projects`). All queries must pass `project="<repo-project-name>"`.
-- Use `search_notes` and `build_context` (with `project`) to find project-specific notes.
-- Read `plans/*` notes for in-progress and recently completed work.
-- Read `decisions/*` notes for pending or unresolved decisions.
-- If present, read `knowledge/*` notes for additional context.
-- Summarize:
-  1. What is currently in progress
-  2. What was completed recently
-  3. What decisions are still pending
-  4. Recommended next actions

.config/opencode/commands/test.md

@@ -1,18 +0,0 @@
----
-description: Test execution workflow using tester subagent
-agent: tester
-subtask: true
-permalink: opencode-config/commands/test
----
-
-Run the relevant test scope and report results.
-
-Requested scope:
-$ARGUMENTS
-
-Requirements:
-
-- Read relevant basic-memory project notes first for testing context (use `project="<repo-project-name>"`).
-- If scope is ambiguous, ask one focused clarification question using the question tool.
-- Prefer `uv run pytest` command patterns for Python projects.
-- Report commands run, pass/fail results, and likely root causes for failures.