oh-my-opencode-slim 2.1.0 → 2.2.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oh-my-opencode-slim",
-  "version": "2.1.0",
+  "version": "2.2.0",
   "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,7 +21,9 @@
 | `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 |
+| `release-smoke-test/` | Orchestrator-only | Packed release-candidate and bugfix validation |
 | `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 +41,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,14 +51,16 @@
 
 ### 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/release-smoke-test/SKILL.md`
   - `src/skills/worktrees/SKILL.md`
   - `src/skills/oh-my-opencode-slim/SKILL.md`
 - `package.json` scripts (`verify:release`, `build`) rely on these assets to ensure install-time skill availability

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/oh-my-opencode-slim/SKILL.md

@@ -122,13 +122,13 @@ Edit the active preset under `presets.<preset>.<agent>`:
   "presets": {
     "openai": {
       "orchestrator": {
-        "model": "openai/gpt-5.5",
+        "model": "openai/gpt-5.6-terra",
         "variant": "high",
         "skills": ["*"],
         "mcps": ["*", "!context7"]
       },
       "librarian": {
-        "model": "openai/gpt-5.4-mini",
+        "model": "openai/gpt-5.6-luna",
         "variant": "low",
         "skills": [],
         "mcps": ["websearch", "context7", "gh_grep"]
@@ -233,7 +233,7 @@ Use this shape as a starting point:
 {
   "agents": {
     "api-reviewer": {
-      "model": "openai/gpt-5.5",
+      "model": "openai/gpt-5.6",
       "variant": "high",
       "prompt": "You review API design, compatibility, error semantics, and migration risk. Return concise findings with file references.",
       "orchestratorPrompt": "Delegate to @api-reviewer for API contract changes, public SDK changes, backwards-compatibility questions, or migration-risk review. Do not use it for routine implementation.",

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

@@ -119,13 +119,13 @@ tarball install.
 mkdir -p "$SMOKE/config"
 cat > "$SMOKE/config/opencode.json" <<EOF
 {
-  "model": "openai/gpt-5.5-fast",
+  "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.5-fast"
+      "model": "openai/gpt-5.6-fast"
     }
   }
 }

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

@@ -0,0 +1,103 @@
+---
+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 release-specific validation, use
+`release-smoke-test`; 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.
 
 ---