oh-my-opencode-serverlocal 0.1.0

package/src/skills/reflect/SKILL.md

@@ -0,0 +1,326 @@
+---
+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>`;
+- run `/reflect --sessions` for session archaeology;
+- 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.
+
+## Session Mode
+
+When the user includes `--sessions` in their reflect command, shift to session
+archaeology: analyze historical OpenCode sessions across all repos to find
+repeated patterns, friction, and improvement opportunities.
+
+### Session Discovery
+
+1. **Load recent sessions** - Query the SQLite database directly:
+   ```bash
+   bun -e "import Database from 'bun:sqlite'; const db = new Database('/home/mhenke/.local/share/opencode/opencode.db'); console.log(db.query('SELECT id, directory, title, agent, model, time_created, cost, tokens_input, tokens_output FROM session ORDER BY time_created DESC LIMIT 50').all())"
+   ```
+   Adjust `LIMIT 50` to `--last N` if specified.
+
+   **Session table columns:** `id, directory, title, agent, model, time_created, cost, tokens_input, tokens_output`
+
+2. **Load session messages** - For each session ID, query the message table:
+   ```bash
+   bun -e "import Database from 'bun:sqlite'; const db = new Database('/home/mhenke/.local/share/opencode/opencode.db'); console.log(db.query('SELECT data FROM message WHERE session_id = ?').all('ses_14de9c68effegtZtlATm42wnz7'))"
+   ```
+
+   **Message table columns:** `id, session_id, time_created, time_updated, data` (data is JSON with role, agent, model, summary, etc.)
+
+### Per-Session Analysis
+
+For each session, analyze and produce a structured summary:
+
+```json
+{
+  "session": "ses_14de9c68effegtZtlATm42wnz7",
+  "project": "/home/user/Projects/oh-my-opencode-slim",
+  "timestamp": "2026-06-10T15:08:45.427Z",
+  "goal": "Fix CI failure",
+  "success": true,
+  "frictions": [
+    "Repeated grep to find test file",
+    "Three failed test runs before passing"
+  ],
+  "recommendations": [
+    "Create /test-ci command"
+  ],
+  "duration_minutes": 18,
+  "models_used": ["opencode/mimo-v2.5-free"],
+  "agents_used": ["orchestrator", "fixer", "explorer"],
+  "tools_used": ["Read", "Edit", "Bash"],
+  "confidence": 0.85
+}
+```
+
+**Confidence scoring:**
+- 0.9-1.0: Clear success/failure, obvious patterns
+- 0.7-0.9: Likely outcome, patterns inferred from tool usage
+- 0.5-0.7: Uncertain outcome, limited evidence
+- <0.5: Skip or mark as "needs more evidence"
+
+### Storage and Caching
+
+Store session summaries in `~/.config/opencode/oh-my-opencode-slim/reflections/sessions/`.
+
+**Cache logic:**
+1. Check if `<session-id>.json` exists in reflections directory
+2. If yes, load it (saves tokens)
+3. If no, analyze session and save summary
+4. Aggregate across all summaries for final report
+
+### Aggregation
+
+After analyzing all sessions, aggregate findings:
+
+1. **Group by theme** - sessions with similar frictions cluster together
+2. **Count frequency** - "42/50 sessions had repeated grep before editing"
+3. **Rank by impact** - prioritize recommendations that appear most often
+4. **Filter noise** - skip one-off issues, focus on repeated patterns
+5. **Cross-reference** - see if patterns correlate with specific models, agents, or repos
+
+**Scope categories:**
+- **Global** - applies to all repos (pattern seen in >50% of repos)
+- **Cross-repo** - applies to specific repos where pattern appears
+- **Project-specific** - only relevant to one repo
+
+### Output Format
+
+Return a compact report with scope and confidence:
+
+```text
+Session Reflection Report
+Analyzing 50 most recent sessions across 8 repos.
+
+Repos analyzed:
+- <repo> (<N> sessions)
+- ... (M more)
+
+Findings
+- <pattern>: N/50 sessions across M repos.
+  - Scope: global | cross-repo (<repos>) | project-specific (<repo>)
+  - Confidence: 0.95
+  - Impact: High | Medium | Low
+
+Recommended changes
+- <asset>: <purpose>
+  - Scope: global | cross-repo (<repos>) | project-specific (<repo>)
+  - Confidence: 0.97
+  - Estimated time saved: High | Medium | Low
+
+Skipped
+- <candidate>: why not worth packaging now.
+  - Scope: <reason>
+  - Confidence: <score>
+
+Needs more evidence
+- <candidate>: what would make it actionable.
+  - Current scope: <what we've seen>
+  - Required scope: <what would confirm>
+```
+
+### Error Handling
+
+**Log file issues:**
+- Log doesn't exist → "No OpenCode log found at <path>. Run OpenCode in at least one repo first."
+- Log is empty → "OpenCode log is empty. No sessions to analyze."
+
+**Session loading issues:**
+- Session ID not loadable → Skip with warning: "Session <id> could not be loaded, skipping."
+- Session has no messages → Skip: "Session <id> has no messages."
+
+**Recovery pattern:**
+- Log the failure
+- Continue with remaining sessions
+- Report failures at end: "3 sessions skipped due to load errors"
+
+## 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
+/reflect --sessions
+/reflect --sessions --last 100
+```
+
+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/simplify/README.md

@@ -0,0 +1,19 @@
+# Simplify Skill
+
+Behavior-preserving code simplification and readability-focused refactoring.
+
+## Overview
+
+This bundled skill helps the `oracle` agent review and simplify code without
+changing behavior. It focuses on readability, maintainability, and reducing
+unnecessary complexity.
+
+## Source
+
+Adapted from Addy Osmani's
+[`code-simplification` skill](https://github.com/addyosmani/agent-skills/blob/main/skills/code-simplification/SKILL.md).
+
+## Installation
+
+Bundled with `oh-my-opencode-slim` and installed automatically when bundled
+skills are enabled via the installer.

package/src/skills/simplify/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: simplify
+description: Simplifies code for clarity without changing behavior. Use for readability, maintainability, and complexity reduction after behavior is understood.
+---
+
+# Code Simplification
+
+## Overview
+
+Simplify code by reducing complexity while preserving exact behavior. The goal is not fewer lines - it's code that is easier to read, understand, modify, and debug. Every simplification must pass a simple test: "Would a new team member understand this faster than the original?"
+
+## When to Use
+
+- After a feature is working and tests pass, but the implementation feels heavier than it needs to be
+- During code review when readability or complexity issues are flagged
+- When you encounter deeply nested logic, long functions, or unclear names
+- When refactoring code written under time pressure
+- When consolidating related logic scattered across files
+- After merging changes that introduced duplication or inconsistency
+
+**When NOT to use:**
+
+- Code is already clean and readable - don't simplify for the sake of it
+- You don't understand what the code does yet - comprehend before you simplify
+- The code is performance-critical and the "simpler" version would be measurably slower
+- You're about to rewrite the module entirely - simplifying throwaway code wastes effort
+
+## The Five Principles
+
+### 1. Preserve Behavior Exactly
+
+Don't change what the code does - only how it expresses it. All inputs, outputs, side effects, error behavior, and edge cases must remain identical. If you're not sure a simplification preserves behavior, don't make it.
+
+Before every change, ask:
+
+- Does this produce the same output for every input?
+- Does this maintain the same error behavior?
+- Does this preserve the same side effects and ordering?
+- Do all existing tests still pass without modification?
+
+### 2. Follow Project Conventions
+
+Simplification means making code more consistent with the codebase, not imposing external preferences.
+
+Before simplifying:
+
+1. Read `AGENTS.md` / project conventions
+2. Study how neighboring code handles similar patterns
+3. Match the project's style for imports, naming, function style, error handling, and type annotations
+
+Simplification that breaks project consistency is not simplification - it's churn.
+
+### 3. Prefer Clarity Over Cleverness
+
+Explicit code is better than compact code when the compact version requires a mental pause to parse.
+
+- Replace nested ternaries with readable control flow
+- Replace dense inline transforms with named intermediate steps when they clarify intent
+- Keep helpful names even if they cost a few extra lines
+
+### 4. Maintain Balance
+
+Watch for over-simplification:
+
+- Don't inline away names that carry meaning
+- Don't merge unrelated logic into one larger function
+- Don't remove abstractions that serve testability or extensibility
+- Don't optimize for line count over comprehension
+
+### 5. Scope to What Changed
+
+Default to simplifying recently modified code. Avoid unrelated drive-by refactors unless explicitly asked.
+
+## Process
+
+### Step 1: Understand Before Touching
+
+Before changing or removing anything, understand why it exists.
+
+Answer:
+
+- What is this code's responsibility?
+- What calls it? What does it call?
+- What are the edge cases and error paths?
+- Are there tests that define expected behavior?
+- Why might it have been written this way?
+
+If you can't answer these, read more context first.
+
+### Step 2: Look for Simplification Opportunities
+
+Signals:
+
+- Deep nesting
+- Long functions with mixed responsibilities
+- Nested ternaries
+- Boolean flag arguments
+- Repeated conditionals
+- Generic or misleading names
+- Duplicated logic
+- Dead code
+- Wrappers or abstractions that add no value
+
+### Step 3: Apply Changes Incrementally
+
+Make one simplification at a time.
+
+For each simplification:
+
+1. Make the change
+2. Run relevant tests
+3. Keep it only if behavior is preserved
+
+Separate refactoring from feature work whenever possible.
+
+### Step 4: Verify the Result
+
+After simplifying, confirm:
+
+- The code is genuinely easier to understand
+- The diff is clean and reviewable
+- Project conventions still match
+- No behavior, error handling, or side effects changed
+
+## Guidance for This Repository
+
+- Prefer straightforward TypeScript over clever compression
+- Preserve existing runtime behavior, tests, and hooks
+- Favor explicit names and smaller focused helpers when they improve readability
+- Keep refactors tightly scoped to the task or review feedback
+
+## Verification Checklist
+
+- [ ] Existing tests pass without modification
+- [ ] Build/typecheck/lint still pass
+- [ ] No unrelated files were refactored
+- [ ] No error handling was weakened or removed
+- [ ] The result is simpler to review than the original

package/src/skills/simplify/codemap.md

@@ -0,0 +1,36 @@
+# src/skills/simplify/
+
+## Responsibility
+
+- Provide a behavior-preserving refactoring skill contract that constrains code cleanup to clarity-focused,
+  low-risk changes.
+- Define explicit quality gates (understand-before-edit, behavior parity, incremental simplification, rollback-friendly diffs)
+  for any simplification task.
+- Ship only metadata; no local runtime state machine is kept in this directory.
+
+## Design
+
+- Contract layer: `SKILL.md` is the executable prompt specification with explicit phases:
+  - pre-change understanding
+  - simplification candidate selection
+  - incremental transformation and verification
+  - final review checklist.
+- Documentation layer: `README.md` explains intent, source provenance, and plugin install behavior.
+- Policy model is declarative (`description`, allowed usage, checklist) consumed by the OpenCode skill executor,
+  without helper scripts or plugin code dependencies.
+
+## Flow
+
+- Agent discovery resolves `src/skills/simplify` as a custom skill entrypoint, then reads `SKILL.md` at runtime.
+- Runtime behavior is gated by `src/cli/custom-skills.ts` (`allowedAgents: ['oracle']`) and by skill permissions
+  computed in `getSkillPermissionsForAgent()`.
+- In practice the workflow is read-only and context-driven: simplify instructions require understanding of callers,
+  edge cases, and tests before mutation, then apply local, scoped refactors with validation.
+- Consumers (Fixer/Oracle/Reviewer tasks) rely on this contract as operational constraints, not as executable TypeScript.
+
+## Integration
+
+- Installed by plugin installer (`installCustomSkills`) using `src/cli/install.ts` via `installCustomSkill()`.
+- Permission surface is enforced by hook layer in `src/hooks/filter-available-skills/index.ts` (`permissionRules`).
+- Release integrity: `scripts/verify-release-artifact.ts` checks for `src/skills/simplify/SKILL.md` in package tarballs.
+- Operationally paired with codemap/fixer flows in `src/index.ts` orchestrations for post-feature readability hardening.

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.