oh-my-opencode-slim 2.0.1 → 2.0.2

package/src/skills/reflect/SKILL.md

@@ -0,0 +1,193 @@
+---
+name: reflect
+description: Review recent work, find repeated workflow patterns, and suggest reusable skills, agents, commands, config changes, or playbooks. Use when the user asks to learn from past sessions, improve recurring workflows, or identify what should be turned into reusable agent instructions.
+---
+
+# Reflect
+
+Reflect is an orchestrator-only workflow for learning from repeated work. It
+looks back over recent sessions, project notes, and existing agent assets, then
+recommends the smallest useful improvement: a skill, custom agent, command,
+configuration change, prompt rule, documentation playbook, or no change.
+
+The goal is to identify real repeated friction and suggest practical improvements with evidence.
+
+## When to Use
+
+Use Reflect when the user asks to:
+
+- run `/reflect` or `/reflect <focus>`;
+- learn from recent sessions or repeated workflows;
+- find work they keep doing manually;
+- improve their oh-my-opencode-slim setup based on actual usage using oh-my-opencode-slim skill;
+- review whether a recurring process should become a reusable playbook;
+- turn repeated workflow friction into a safer future default.
+
+Do not use Reflect for ordinary implementation work, one-off debugging, broad
+architecture review, or speculative agent creation without workflow evidence.
+
+## Core Contract
+
+Reflect must be conservative and evidence-driven.
+
+Required behavior:
+
+- inspect existing assets before suggesting new ones;
+- prefer recent, repeated, user-visible friction over isolated incidents;
+- recommend the smallest useful form;
+- treat "create nothing" as a successful result when evidence is weak;
+- ask before changing prompts, skills, commands, agents, MCP access, or config;
+- avoid duplicating existing assets;
+- explain restart requirements for OpenCode config, prompt, agent, skill, MCP, or
+  plugin changes.
+
+## Evidence Sources
+
+Use available evidence in this order:
+
+1. Current conversation and explicit user instructions.
+2. Project-local guidance and memories, such as `AGENTS.md`, `.opencode/`,
+   `.slim/`, notes, checkpoints, task progress files, and codemaps.
+3. Existing skills, commands, agents, prompt overrides, MCP permissions, and
+   oh-my-opencode-slim configuration.
+4. Recent OpenCode logs or session artifacts if they are available and safe to
+   inspect.
+5. External docs only when a proposed workflow depends on a third-party tool or
+   library whose behavior needs confirmation.
+
+Respect privacy and safety boundaries. Do not inspect unrelated personal files,
+credentials, private messages, or external accounts unless the user explicitly
+asks and the workflow requires it.
+
+## Workflow
+
+Reflect can be triggered directly:
+
+```text
+/reflect
+/reflect release workflow and checks
+```
+
+With no arguments, review recent work broadly. With arguments, focus the review
+on that workflow area while still checking whether existing assets already cover
+it.
+
+### 1. Inventory Existing Assets
+
+Before proposing anything, identify what already exists:
+
+- bundled and user-installed skills;
+- custom agents and their `orchestratorPrompt` guidance;
+- custom commands;
+- prompt overrides and append files;
+- active oh-my-opencode-slim preset, model routing, skills, and MCP permissions;
+- project playbooks, docs, codemaps, and local workflow notes.
+
+If an existing asset already covers the candidate, recommend extending or using
+that asset instead of creating a near-duplicate.
+
+### 2. Find Repeated Workflow Patterns
+
+Look for repeated signals such as:
+
+- the same command sequence appears across sessions;
+- the user repeatedly asks for the same review, setup, release, or debugging
+  process;
+- the same manual research or context-gathering steps keep recurring;
+- the same specialist routing decision is repeatedly needed;
+- the same project-specific rule is repeatedly re-explained;
+- repeated failures happen because an agent lacks a stable instruction, tool, or
+  permission boundary.
+
+Strong candidates usually have at least two occurrences, stable inputs, a clear
+output, and a clear stopping condition.
+
+### 3. Score Candidates
+
+For each candidate, decide:
+
+- **Frequency:** How often has it happened?
+- **Cost:** Does it waste meaningful time, context, money, or attention?
+- **Risk:** Does inconsistent execution cause bugs, regressions, bad decisions,
+  or unsafe changes?
+- **Stability:** Are the inputs and desired output predictable?
+- **Coverage:** Is there already an asset that handles it well?
+
+Only recommend creating or changing assets when confidence is high.
+
+### 4. Choose the Smallest Useful Form
+
+Pick the least powerful form that solves the repeated problem:
+
+- **Prompt/config rule:** a small behavior change to an existing agent.
+- **Skill:** reusable workflow guidance for a task shape.
+- **Command:** a repeatable manual trigger with stable inputs.
+- **Custom agent:** a distinct specialist lane with clear delegation rules.
+- **MCP/tool permission change:** a safe access adjustment for an existing agent.
+- **Project playbook/doc:** human-readable process guidance when automation is too
+  heavy.
+- **Skip:** weak, one-off, ambiguous, sensitive, or already-covered work.
+
+Avoid creating custom agents when a prompt rule or skill is enough. Avoid skills
+when a short project playbook is enough. Avoid config changes when the benefit is
+unclear.
+
+### 5. Propose Before Changing
+
+Unless the user explicitly requested a specific edit, present a concise proposal
+before writing files or changing config:
+
+```text
+Found 2 strong repeated workflows and 1 weak candidate.
+
+Recommended:
+- Add a small orchestrator prompt rule for <workflow> because <evidence>.
+- Extend existing <skill> instead of creating a new one because <overlap>.
+
+Skip:
+- <candidate> because it only appeared once.
+
+Proceed with the proposed edits?
+```
+
+When applying changes, preserve existing user settings and prefer narrow,
+append-only edits.
+
+## Output Format
+
+Return a compact report:
+
+```text
+Findings
+- <workflow>: evidence, frequency/confidence, recommended form.
+
+Recommended changes
+- <asset/config/doc>: one-line purpose and why this is the smallest useful form.
+
+Skipped
+- <candidate>: why not worth packaging now.
+
+Needs more evidence
+- <candidate>: what would make it actionable.
+```
+
+If nothing qualifies, say:
+
+```text
+No strong repeated workflow found. I would not add or change any reusable assets
+yet.
+```
+
+## Guardrails
+
+- Do not manufacture assets to justify the workflow.
+- Do not create overlapping skills or agents.
+- Do not silently change global config, prompts, or permissions.
+- Do not add broad instructions that make agents more eager, expensive, or
+  invasive without a clear benefit.
+- Do not overfit to a single session unless the user explicitly asks for that
+  exact reusable workflow.
+- Do not use private or sensitive material as examples in generated assets.
+- When config, prompt, agent, skill, MCP, or plugin files change, tell the user:
+  "This should apply on the next OpenCode run; restart OpenCode if you need it
+  immediately."

package/src/skills/worktrees/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: worktrees
+description: Manage Git worktrees as OMO safe isolated coding lanes for complex, risky, or parallel work.
+---
+
+# Worktrees Orchestration Protocol
+
+The `worktrees` skill provides an opinionated, safe orchestration protocol for
+managing Git worktrees as isolated coding lanes. Its value is giving the Orchestrator a consistent OMO workflow for parallel agents, risky experiments, integration review, and cleanup.
+
+## Core Contract
+
+This is an **orchestrator-only** workflow. Other specialists such as `@fixer`
+or `@designer` can be assigned tasks inside a worktree lane, but the
+Orchestrator owns lane planning, branch/path selection, file ownership,
+delegation, diff validation, integration, and cleanup.
+
+All worktrees reside under the default path:
+
+```text
+.slim/worktrees/<slug>/
+```
+
+Do not create worktrees as sibling directories of the main repository.
+
+### State Tracking (`.slim/worktrees.json`)
+
+Use the optional local metadata manifest `.slim/worktrees.json` to maintain
+structural tracking:
+
+```json
+{
+  "version": "1.0.0",
+  "updatedAt": "2026-06-14T00:00:00.000Z",
+  "lanes": [
+    {
+      "slug": "feature-auth-v2",
+      "branch": "omos/feature-auth-v2",
+      "path": ".slim/worktrees/feature-auth-v2",
+      "base": "main",
+      "purpose": "refactor authentication flow to use OAuth2",
+      "owner": "orchestrator",
+      "status": "active",
+      "areas": ["src/auth", "src/config"],
+      "createdAt": "2026-06-14T12:00:00.000Z"
+    }
+  ]
+}
+```
+
+If `.slim/worktrees.json` does not exist, create it when initializing a lane,
+and keep it updated as lanes are transitioned, integrated, or pruned. Treat it
+as local workflow metadata by default; ask before making it part of a committed
+project convention.
+
+---
+
+## Safety Guidelines
+
+Before executing any Git mutation command, the Orchestrator must observe the
+following guards:
+
+### 1. Pre-Flight Checklist
+- Confirm the current directory is inside a Git repository.
+- Check the current branch, base branch, and dirty/uncommitted state.
+- Inspect the output of `git worktree list` to avoid path or branch conflicts.
+- Ensure the branch name (e.g. `omos/<slug>` or custom project convention) does not already exist locally or on remote.
+- Ensure `.slim/worktrees/` is ignored by Git before creating nested worktrees.
+
+### 2. Mandatory User Confirmation
+You must seek explicit user confirmation before executing:
+- `git worktree add` or `git worktree remove`
+- Branch creation, deletion, or renaming
+- Merges, rebases, or cherry-picks
+- `git prune` or `git worktree prune`
+- Destructive commands (e.g., `git reset --hard`, `git clean`, `git push --force`, or removing a dirty worktree directory).
+
+Never execute destructive commands, delete branches, remove dirty worktrees, or
+clean uncommitted changes without explicit user confirmation for that exact
+operation.
+
+### 3. Ignore File Setup
+
+Before creating lanes, add or update managed marker blocks only.
+
+`.gitignore`:
+
+```gitignore
+# BEGIN oh-my-opencode-slim worktrees
+.slim/worktrees/
+.slim/worktrees.json
+# END oh-my-opencode-slim worktrees
+```
+
+`.ignore`:
+
+```ignore
+# BEGIN oh-my-opencode-slim worktrees
+!.slim/
+!.slim/worktrees.json
+!.slim/worktrees/
+!.slim/worktrees/**
+# END oh-my-opencode-slim worktrees
+```
+
+---
+
+## Workflow Guide
+
+### Phase 1: Planning & Setup
+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.
+5. Run:
+   ```bash
+   git worktree add -b <branch-name> .slim/worktrees/<slug> <base-commit/branch>
+   ```
+6. Register the metadata in `.slim/worktrees.json`.
+
+### Phase 2: Execution & Delegation
+1. Run all sub-agents with their working directory set strictly to the worktree
+   path, such as `.slim/worktrees/<slug>`.
+2. Do not modify the main checkout for lane work. Keep build, test, and edit
+   operations isolated inside the lane.
+3. Track file or folder ownership per lane to avoid merge conflicts between
+   parallel agents.
+4. Commit progress within the worktree only when the user asked for commits or
+   approved local checkpoint commits.
+
+### Phase 3: Integration & Validation
+Before merging or integrating the worktree branch:
+1. Run lint, build, formatting, and unit tests inside the worktree directory.
+2. Generate and display a clear diff comparing the worktree branch to the
+   integration base branch.
+3. Ask the user for confirmation to integrate.
+4. Perform the approved integration, such as merge or cherry-pick, from the main
+   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:
+   ```bash
+   git worktree remove .slim/worktrees/<slug>
+   ```
+5. Update `.slim/worktrees.json` to mark the lane as `archived` or remove it.
+
+---
+
+## When to Use vs. Not Use
+
+### Use When:
+- Performing risky or destructive refactoring that could break the active working environment.
+- Working on parallel tasks/bugfixes that require switching contexts without committing half-finished work.
+- Running independent background agents on separate branches.
+- Conducting exploratory spikes or prototyping that may be discarded.
+- Isolating third-party packages or complex upgrades.
+- Explicitly asked to use worktrees for a specific task.
+
+### Do NOT Use When:
+- Making simple single-file changes, documentation updates, or minor bug fixes.
+- Working in a git repository that is not fully initialized or has complex multi-submodule states not supported easily by worktrees.

package/dist/config/fallback-chains.d.ts

@@ -1 +0,0 @@
-export declare function normalizeFallbackChainsForPreset(chains: Record<string, string[] | undefined>, presetName: string | null | undefined): Record<string, string[]>;

package/dist/hooks/apply-patch/patch.d.ts

@@ -1,2 +0,0 @@
-export { parsePatch } from './codec';
-export { preparePatchChanges, rewritePatch, rewritePatchText, } from './operations';

package/dist/hooks/delegate-task-retry/guidance.d.ts

@@ -1,2 +0,0 @@
-import { type DetectedError } from './patterns';
-export declare function buildRetryGuidance(errorInfo: DetectedError): string;

package/dist/hooks/delegate-task-retry/index.d.ts

@@ -1,4 +0,0 @@
-export { buildRetryGuidance } from './guidance';
-export { createDelegateTaskRetryHook } from './hook';
-export type { DelegateTaskErrorPattern, DetectedError } from './patterns';
-export { DELEGATE_TASK_ERROR_PATTERNS, detectDelegateTaskError, } from './patterns';

package/dist/hooks/json-error-recovery/index.d.ts

@@ -1 +0,0 @@
-export { createJsonErrorRecoveryHook, JSON_ERROR_PATTERNS, JSON_ERROR_REMINDER, JSON_ERROR_TOOL_EXCLUDE_LIST, } from './hook';

package/dist/utils/env.d.ts

@@ -1 +0,0 @@
-export declare function getEnv(name: string): string | undefined;