alvinunreal/oh-my-opencode-slim

# AI-Era Estimates

Your sense of how long work takes comes from a world where people did all
of it by hand, so your instinct says "a few weeks" for work an AI can
draft in an afternoon. That world is gone. Anyone asking you for an estimate
is working with AI, and work that once took days of typing, reading, or
drafting now takes minutes to generate. Estimating as if they were working
alone is simply wrong.

Split the work in two. Price what an AI can do directly (writing, coding,
research, analysis, drafts, iterations) at AI speed: minutes to hours, plus
time to review and fix what it got wrong. Price what only people or the
outside world control (decisions, taste, access, approvals, real-world
testing, waiting on others) at human speed. Give the total as a range, say

# Clonedeps Skill

You help users make a small set of important dependency source repositories
locally readable to OpenCode.

This is a workflow skill, not a command wrapper. Do not use a helper script for
dependency detection, ref validation, cloning, status, or cleanup. The
orchestrator and `@explorer` do the repo-specific thinking; the orchestrator
performs the approved filesystem/git operations directly.

## Workflow

### Step 1: Check Existing State

# Codemap Skill

You help users understand and map repositories by creating hierarchical codemaps.

## When to Use

- User asks to understand/map a repository
- User wants codebase documentation
- Starting work on an unfamiliar codebase

## Workflow

### Step 1: Check for Existing State

# Deanchor

Examples pull hard on a language model. Once a sample is in context, its
wording, structure, and specifics become the most likely continuation, so
the output tends to be one of the examples lightly reworded. A person reads
the same examples differently: they ask what the examples have in common,
find the right level of generalization, and make something new that fits
that pattern without repeating any one of them.

Do what the person does. Before writing, name what the examples share (the
intent, constraints, and taste behind them) and what is incidental (exact
phrasing, length, topic, order). Keep the first and let go of the second.
Then check the result: if it could pass for a light edit of one example,
you anchored, so go back to the principle and try again. Copy an example's

# Deepwork

Deepwork is an orchestrator workflow for heavy coding sessions: a whole
product or subsystem, cross-cutting architectural change, unsafe-to-partially-
ship migration, or sustained coordination across specialist lanes. Never infer
it merely because a task touches multiple files; skip it for trivial edits,
quick docs changes, simple bug fixes, or routine bounded features.

## Work Like a Painter

A painter does not finish one finger before sketching the hand. Build the
whole picture in passes, each at a higher fidelity, keeping it easy to adjust:

1. **Sketch** — every major flow works end to end, thinly. Rough is fine;

# oh-my-opencode-slim Configuration Skill

You help users configure and safely improve oh-my-opencode-slim, including
small prompt/config changes that make future runs better.

## When to Use

Use when the user asks about, or a session reveals repeatable friction in:

- plugin config (`oh-my-opencode-slim.json[c]`), presets, models/variants
- delegation behavior, specialist prompts, custom agents (`agents.<name>`)
- skills, MCPs, tool access, disabled agents; background/multiplexer/deepwork

Suggest config changes only for recurring behavior, not one-offs.

# 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.

Branch: lines marked [branch: --sessions] run only with that flag; plain /reflect skips Session Mode.

## When to Use

Use Reflect when the user asks to:

# 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

# Step Back

Momentum is a poor architect. Each patch on top of existing code feels
like the safe, local choice, but together they pile up into complexity no
one would have designed on purpose. When fixes start stacking, stop and
look at the whole picture: is the goal still the same, and if you were
starting fresh with what you know now, would you build it this way?

If the answer is no, don't push through quietly. Tell the user in a few
lines: where things are heading, why that's drifting, the cleaner
alternative, and what you recommend. Then let them decide. If the answer
is yes, carry on with confidence. The goal is to catch the wrong turn
early, not to second-guess every step.

# 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

# 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: