oh-my-opencode-slim 2.1.1 → 2.2.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oh-my-opencode-slim",
-  "version": "2.1.1",
+  "version": "2.2.1",
   "description": "Lightweight agent orchestration plugin for OpenCode - a slimmed-down fork of oh-my-opencode",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/src/skills/clonedeps/SKILL.md

@@ -100,7 +100,37 @@ The orchestrator owns final approval. Before cloning:
 5. Ask for confirmation before network cloning unless the user explicitly asked
    to clone immediately.
 
-### Step 4: Clone Sources Manually
+### Step 4: Update Ignore Files
+
+Before cloning artifacts or cleaning cloned dependencies, inspect existing
+`.gitignore` and `.ignore`. Update the managed block in place when present;
+otherwise append it. Add only the missing exact lines below, never duplicate
+entries or modify unrelated rules. These blocks keep cloned artifacts git-local
+while the `.ignore` allowlist keeps them readable to OpenCode.
+
+`.gitignore`:
+
+```gitignore
+# BEGIN oh-my-opencode-slim clonedeps
+.slim/clonedeps/repos/
+# END oh-my-opencode-slim clonedeps
+```
+
+`.ignore`:
+
+```ignore
+# BEGIN oh-my-opencode-slim clonedeps
+!.slim/
+!.slim/clonedeps.json
+!.slim/clonedeps/
+!.slim/clonedeps/repos/
+!.slim/clonedeps/repos/**
+.slim/clonedeps/repos/**/.git/
+.slim/clonedeps/repos/**/.git/**
+# END oh-my-opencode-slim clonedeps
+```
+
+### Step 5: Clone Sources Manually
 
 Create one folder per source repository under:
 
@@ -135,7 +165,7 @@ Safe manual git pattern:
 
 Do not run dependency install/build/test scripts from cloned repositories.
 
-### Step 5: Write Local State
+### Step 6: Write Local State
 
 Write `.slim/clonedeps.json` so future agents know what exists:
 
@@ -173,33 +203,6 @@ Do not add `.slim/clonedeps.json` to `.gitignore`. It is small, reviewable
 project metadata that can be committed. Only the cloned repository contents
 under `.slim/clonedeps/repos/` should be ignored.
 
-### Step 6: Update Ignore Files
-
-Update `.gitignore` with an idempotent marker block:
-
-```gitignore
-# BEGIN oh-my-opencode-slim clonedeps
-.slim/clonedeps/repos/
-# END oh-my-opencode-slim clonedeps
-```
-
-Update `.ignore` so OpenCode can read the cloned source while git still ignores
-it:
-
-```ignore
-# BEGIN oh-my-opencode-slim clonedeps
-!.slim/
-!.slim/clonedeps.json
-!.slim/clonedeps/
-!.slim/clonedeps/repos/
-!.slim/clonedeps/repos/**
-.slim/clonedeps/repos/**/.git/
-.slim/clonedeps/repos/**/.git/**
-# END oh-my-opencode-slim clonedeps
-```
-
-Only edit content inside these marker blocks.
-
 ### Step 7: Register Dependency Source in AGENTS.md
 
 After successful cloning, update the repository root `AGENTS.md` so future

package/src/skills/codemap.md

@@ -11,7 +11,7 @@
 
 ### Skill Registry
 
-- `CUSTOM_SKILLS` in `src/cli/custom-skills.ts` is the authoritative skill manifest for bundled skills
+- `CUSTOM_SKILLS` in `src/cli/custom-skills-registry.ts` is the authoritative skill manifest for bundled skills
 - Each entry maps folder name + `sourcePath` to an install-time consumer
 - Skills are categorized by purpose and access scope:
 
@@ -21,6 +21,7 @@
 | `clonedeps/` | General-purpose | Workflow skill for dependency source mirroring and inspection |
 | `simplify/` | General-purpose | Readability and maintainability guidance skill |
 | `deepwork/` | Orchestrator-only | Heavy coding sessions, multi-phase implementation, and risky refactors |
+| `verification-planning/` | Orchestrator-only | Project-specific evidence planning and verification affordances before non-trivial implementation |
 | `reflect/` | Orchestrator-only | Learning from repeated work and suggesting reusable improvements |
 | `worktrees/` | Orchestrator-only | Safe Git worktree lanes for parallel, risky, or isolated work |
 | `oh-my-opencode-slim/` | Orchestrator-only | Plugin configuration and self-improvement guidance |
@@ -39,7 +40,7 @@
 
 ## Flow
 
-1. **Skill Discovery**: `src/cli/custom-skills.ts` defines `CUSTOM_SKILLS` array with skill metadata
+1. **Skill Discovery**: `src/cli/custom-skills-registry.ts` defines `CUSTOM_SKILLS` array with skill metadata
 2. **Installation**: `bun run install` delegates to `src/cli/install.ts`, where `installCustomSkills()` gates copying of each `CUSTOM_SKILLS` entry
 3. **Validation**: `installCustomSkill()` computes `packageRoot`, validates `sourcePath`, then performs a recursive directory copy via `copyDirRecursive()`
 4. **Distribution**: During plugin release, `package.json` `files` whitelist ensures `src/skills/**` are included in the published tarball
@@ -49,13 +50,14 @@
 
 ### Build & Release Dependencies
 
-- `src/cli/custom-skills.ts`: Source-of-truth registry consumed by installer and permission helpers
+- `src/cli/custom-skills-registry.ts`: Source-of-truth registry consumed by installer and permission helpers
 - `src/cli/install.ts`: Contains `installCustomSkills()` and `installCustomSkill()` functions
 - `verify-release-artifact.ts`: Enforces artifact completeness by asserting key bundled skill payloads are present in the tarball:
   - `src/skills/simplify/SKILL.md`
   - `src/skills/codemap/SKILL.md`
   - `src/skills/clonedeps/SKILL.md`
   - `src/skills/deepwork/SKILL.md`
+  - `src/skills/verification-planning/SKILL.md`
   - `src/skills/reflect/SKILL.md`
   - `src/skills/worktrees/SKILL.md`
   - `src/skills/oh-my-opencode-slim/SKILL.md`

package/src/skills/deepwork/SKILL.md

@@ -1,13 +1,18 @@
 ---
 name: deepwork
-description: Orchestrator-only workflow for heavy coding sessions, multi-phase implementation, and risky refactors. Use for complex work that needs planning, review gates, and persistent progress tracking.
+description: High-cost orchestrator workflow for large, high-risk, multi-phase coding efforts with meaningful dependencies and review gates. Do not activate for routine multi-file changes.
 ---
 
 # Deepwork
 
-Deepwork is an orchestrator workflow for heavy coding sessions. Use it when the
-work is broad, risky, multi-file, or likely to span several implementation
-phases. Do not use it for trivial edits, quick docs changes, or simple bug fixes.
+Deepwork is an orchestrator workflow for heavy coding sessions. Use it only
+when the work is clearly large or high-risk: multiple dependent phases,
+cross-cutting architectural change, unsafe-to-partially-ship migration, or
+sustained coordination across several specialist lanes.
+
+Do not infer Deepwork merely because a task touches multiple files. Do not use
+it for trivial edits, quick docs changes, simple bug fixes, or routine bounded
+features.
 
 ## Core Contract
 
@@ -16,6 +21,10 @@ not as the default implementation worker.
 
 Required behavior:
 
+- before planning, delegation, or creating a deepwork state file, inspect the
+  existing `.gitignore` and `.ignore`; add only missing entries, without
+  duplicates, so `.gitignore` contains `.slim/deepwork/` and `.ignore` contains
+  `!.slim/deepwork/` and `!.slim/deepwork/**`;
 - keep OpenCode todos aligned with the active deepwork phase;
 - create and maintain a local markdown progress file under `.slim/deepwork/`;
 - write valuable research findings into that file as confirmed research context
@@ -65,8 +74,8 @@ Create a task-specific file such as:
 .slim/deepwork/<short-task-slug>.md
 ```
 
-Keep `.slim/deepwork/` out of git, but make it readable to OpenCode. Ensure the
-project ignore files include:
+Before creating this file—and before planning or delegation—inspect the existing
+`.gitignore` and `.ignore`. Add only missing entries and do not add duplicates:
 
 ```gitignore
 # .gitignore
@@ -79,6 +88,8 @@ project ignore files include:
 !.slim/deepwork/**
 ```
 
+These rules keep deepwork state git-local while allowing OpenCode to read it.
+
 Do not follow a rigid template. Choose whatever markdown structure best fits the
 work. The file only needs to remain useful as persistent session state and should
 capture, as applicable:

package/src/skills/verification-planning/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: verification-planning
+description: Verification planning for non-trivial coding work. Use before implementing a feature, bug fix, refactor, cross-system change, or high-confidence behavior change that needs a credible project-specific evidence path.
+---
+
+# Verification Planning
+
+## Build an evidence path
+
+Before changing a non-trivial system, build an **evidence path**: a
+project-specific route from the claim being made to evidence that can establish,
+limit, or refute it.
+
+The purpose is not to select a familiar technique. The purpose is to decide how
+this system can reveal the truth of this particular change.
+
+## 1. Frame the claim
+
+State the behavior that needs to become true and the conditions that could make
+a confident conclusion wrong.
+
+Consider what must change, what must remain true, where the behavior crosses a
+boundary, and which failure would matter most.
+
+**Complete when:** the claim, its meaningful uncertainty, and its important
+failure modes are concrete enough to investigate.
+
+## 2. Design the evidence path
+
+Derive possible evidence paths from the system itself: its controllable inputs,
+observable effects, state transitions, invariants, boundaries, artifacts, and
+ability to repeat or reverse a scenario.
+
+Generate alternatives before choosing. Prefer the path that produces a
+trustworthy conclusion with proportionate cost, safety, and effort.
+
+**Complete when:** there is a preferred path, its limitations are understood,
+and a weaker or stronger alternative is available if circumstances change.
+
+## 3. Create a verification affordance when needed
+
+When the existing system leaves the decisive truth too indirect or ambiguous,
+extend the evidence path with a **verification affordance**: the smallest
+capability that makes the relevant state controllable, observable, repeatable,
+and diagnosable for an agent.
+
+Ask what capability would let an agent establish the claim directly, repeat the
+scenario from a known state, and explain a failure without inference. Prefer an
+affordance that strengthens directness, determinism, agent-legibility,
+isolation, resetability, or future reuse.
+
+Treat the affordance as part of the evidence path, not an automatic product
+feature. Decide deliberately whether it is temporary or durable before building
+it.
+
+**Complete when:** the chosen path can establish the claim directly enough for
+its stakes, and any needed affordance has a defined lifecycle.
+
+## 4. Research when the path is unknown
+
+When the right evidence path depends on an unfamiliar dependency, framework,
+external service, or rapidly changing capability, ask `@librarian` for focused
+research before committing to an approach.
+
+Ask for official or project-specific facilities, constraints, and trade-offs
+that affect this exact verification problem. Use existing project evidence
+directly when it already resolves the choice.
+
+**Complete when:** the chosen path rests on known capabilities and real
+constraints rather than assumption.
+
+## 5. Make the path runnable
+
+Prepare only the support needed to follow the evidence path reliably. Keep the
+support narrow, repeatable, and safe to inspect.
+
+Decide whether that support has recurring value or exists only to resolve the
+current uncertainty. Retain durable value deliberately; remove temporary
+support once it has served its purpose.
+
+Ask before introducing dependencies, persistent diagnostic surfaces, or
+structural changes whose sole purpose is evidence gathering.
+
+**Complete when:** the path can be followed without guessing about setup,
+state, or interpretation.
+
+## 6. Close the evidence path
+
+After implementation, follow the planned path and interpret the resulting
+evidence against the original claim.
+
+Report whether the claim was established, limited, or refuted; distinguish
+known facts from remaining uncertainty.
+
+**Complete when:** a future reader can see what supports the conclusion and
+what remains outside its reach.
+
+## Scope
+
+Use this skill proportionately. Small mechanical changes can follow ordinary
+project checks directly. For larger multi-phase work, let this skill establish
+the evidence path that later work follows.

package/src/skills/worktrees/SKILL.md

@@ -81,7 +81,11 @@ operation.
 
 ### 3. Ignore File Setup
 
-Before creating lanes, add or update managed marker blocks only.
+Before creating or cleaning lanes, inspect existing `.gitignore` and `.ignore`.
+Update the managed block in place when present; otherwise append it. Add only
+the missing exact lines below, never duplicate entries or modify unrelated
+rules. These blocks keep lane artifacts git-local while the `.ignore` allowlist
+keeps them readable to OpenCode.
 
 `.gitignore`:
 
@@ -111,7 +115,8 @@ Before creating lanes, add or update managed marker blocks only.
 1. Identify the task scope and determine a short `<slug>` for the worktree.
 2. Formulate a branch name. Default to `omos/<slug>` unless project/user conventions dictate otherwise.
 3. Validate repository safety. Ask the user for confirmation to initialize the lane.
-4. Ensure the managed ignore blocks are present.
+4. Before creating the lane, ensure the managed ignore blocks are present using
+   the Ignore File Setup rules above.
 5. Run:
    ```bash
    git worktree add -b <branch-name> .slim/worktrees/<slug> <base-commit/branch>
@@ -138,14 +143,16 @@ Before merging or integrating the worktree branch:
    checkout or the user-approved integration checkout.
 
 ### Phase 4: Cleanup & Pruning
-1. Ensure all changes are safely merged or archived.
-2. Confirm the worktree has no uncommitted changes.
-3. Request user approval to remove the worktree.
-4. Safely remove the worktree using:
+1. Before cleaning the lane, ensure the managed ignore blocks follow the Ignore
+   File Setup rules above.
+2. Ensure all changes are safely merged or archived.
+3. Confirm the worktree has no uncommitted changes.
+4. Request user approval to remove the worktree.
+5. Safely remove the worktree using:
    ```bash
    git worktree remove .slim/worktrees/<slug>
    ```
-5. Update `.slim/worktrees.json` to mark the lane as `archived` or remove it.
+6. Update `.slim/worktrees.json` to mark the lane as `archived` or remove it.
 
 ---
 

package/src/skills/release-smoke-test/SKILL.md

@@ -1,159 +0,0 @@
----
-name: release-smoke-test
-description: Test an oh-my-opencode-slim release candidate or bugfix before publishing. Use when validating a packed plugin artifact, release branch, crash fix, OpenCode runtime compatibility, or model-specific smoke test such as OpenCode 1.17.11 message transform regressions.
----
-
-# Release Smoke Test
-
-Use this skill to validate an `oh-my-opencode-slim` release candidate before
-public npm publish. Test the packed artifact, not `@latest` and not the source
-tree.
-
-## Core Workflow
-
-1. Start from the release-prep branch or commit.
-2. Build and pack the candidate.
-3. Install the tarball into a throwaway app.
-4. Create an isolated OpenCode config pointing at the installed
-   `node_modules/oh-my-opencode-slim/dist/index.js`.
-5. Run `opencode debug config` and verify `plugin_origins` contains only the
-   intended plugin when doing an isolation smoke.
-6. Run non-pure `opencode run --print-logs --log-level DEBUG`.
-7. Search isolated logs for the original crash signature.
-8. Record exact artifact, model, OpenCode version, command shape, result, and
-   limitations on the release issue or PR.
-
-## Pack Candidate
-
-Use a temp directory so release validation never depends on the local package
-cache.
-
-```bash
-SMOKE=/tmp/oh-my-opencode-slim-release-smoke
-rm -rf "$SMOKE"
-mkdir -p "$SMOKE/pkg" "$SMOKE/app" "$SMOKE/home" "$SMOKE/xdg/opencode" "$SMOKE/run"
-
-bun run build
-npm pack --pack-destination "$SMOKE/pkg"
-```
-
-Install the tarball:
-
-```bash
-cd "$SMOKE/app"
-bun init -y
-bun add "$SMOKE/pkg"/oh-my-opencode-slim-*.tgz
-node -p "require('./node_modules/oh-my-opencode-slim/package.json').version"
-```
-
-## Isolated Config
-
-Write the minimal OpenCode config:
-
-```bash
-cat > "$SMOKE/xdg/opencode/opencode.json" <<EOF
-{
-  "model": "opencode/deepseek-v4-flash-free",
-  "plugin": [
-    "file://$SMOKE/app/node_modules/oh-my-opencode-slim/dist/index.js"
-  ],
-  "agent": {
-    "orchestrator": {
-      "model": "opencode/deepseek-v4-flash-free"
-    }
-  }
-}
-EOF
-```
-
-Use `env -i` for the cleanest smoke. This strips host `OPENCODE_*`, `ORCA_*`,
-and project overlay variables that can silently add plugins or provider aliases.
-
-```bash
-env -i PATH="$PATH" HOME="$SMOKE/home" XDG_CONFIG_HOME="$SMOKE/xdg" \
-  opencode debug config
-```
-
-Confirm:
-
-- `plugin_origins` has exactly one entry.
-- That entry points to the temp app's packed `dist/index.js`.
-- The model is the one intended for the smoke.
-
-If OpenCode needs provider aliases from the host environment, run a second
-non-isolated model-specific smoke and clearly label it as weaker isolation.
-
-## Runtime Smoke
-
-Run the actual prompt with timeout:
-
-```bash
-env -i PATH="$PATH" HOME="$SMOKE/home" XDG_CONFIG_HOME="$SMOKE/xdg" \
-  timeout 120 \
-  opencode run --print-logs --log-level DEBUG "Say OK only."
-```
-
-Expected result:
-
-```text
-OK
-```
-
-Search logs for the bug signature. For the OpenCode 1.17.11 malformed-message
-crash, use:
-
-```bash
-rg "message\\.info\\.role|undefined is not an object|Cannot read properties of undefined|TypeError" \
-  "$SMOKE/home/.local/share/opencode/log" -n 2>/dev/null || true
-```
-
-No matches should appear.
-
-## OpenAI / Host-Provider Smoke
-
-If the fully isolated environment cannot resolve OpenAI provider aliases, run a
-separate host-provider smoke while keeping the plugin path pointed at the
-tarball install.
-
-```bash
-mkdir -p "$SMOKE/config"
-cat > "$SMOKE/config/opencode.json" <<EOF
-{
-  "model": "openai/gpt-5.6-fast",
-  "plugin": [
-    "file://$SMOKE/app/node_modules/oh-my-opencode-slim/dist/index.js"
-  ],
-  "agent": {
-    "orchestrator": {
-      "model": "openai/gpt-5.6-fast"
-    }
-  }
-}
-EOF
-
-OPENCODE_CONFIG_DIR="$SMOKE/config" \
-  timeout 120 \
-  opencode run --print-logs --log-level DEBUG "Say OK only."
-```
-
-Report this as a host-provider smoke because existing project, user, or Orca
-OpenCode config may still merge in. Use `opencode debug config` to disclose
-what else loaded.
-
-## Reporting Template
-
-```markdown
-## Release-candidate smoke validation
-
-- Commit under test:
-- Tarball:
-- Installed package version:
-- OpenCode version:
-- Config isolation: sanitized `env -i` / host-provider
-- Plugin origin:
-- Model:
-- Command:
-- Result:
-- Crash signature search:
-- Limitations:
-```