opencodekit 0.21.10 → 0.23.0

package/dist/template/.opencode/skill/agent-evals/SKILL.md

@@ -1,208 +0,0 @@
----
-name: agent-evals
-description: Use when adding/changing a skill, command, or agent prompt and you want evidence it actually helps — not just intuition. Defines bounded-task evals, no-skill baselines, deterministic verifiers, JSONL trace logs, and when to skip eval. Adapted from OpenAI eval guide, OpenHands "evaluating agent skills", Anthropic "demystifying evals".
----
-
-# Agent Evals
-
-> Without evals, every skill ships on vibes. The harness-engineering literature is unanimous: **measured changes beat believed-changes**. This skill gives you the smallest workable eval loop.
-
-## When to Use
-
-Run an eval when:
-
-- Adding a new skill that claims to improve outcomes (`anti-ai-slop`, `prompt-leverage`, `condition-based-waiting`)
-- Changing a prompt or instruction in an agent (`build`, `plan`, `review`)
-- Comparing two approaches and you don't know which is better
-- A skill is suspected of being inert ("does this even do anything?")
-
-**Skip eval when:**
-
-- The change is mechanical (rename, refactor, lint fix)
-- The change is a one-shot fix with obvious verification (test passes / build green)
-- The skill is purely procedural with deterministic output (workspace setup)
-
-## Core Principle: Bounded + Baseline + Verifier
-
-Three ingredients. Skip any one and the eval is theatre.
-
-1. **Bounded task** — a concrete prompt with a definite finish line, runnable in <5 minutes
-2. **No-skill baseline** — the same task run **without** the skill loaded, for comparison
-3. **Deterministic verifier** — a check that returns pass/fail without human judgment
-
-If you cannot write the verifier, the skill's value is unmeasurable and you are guessing.
-
-## Eval Loop (Minimum Viable)
-
-### Step 1: Define the task
-
-Pick a real failure mode the skill targets. One paragraph, copy-pastable as a prompt.
-
-```markdown
-## Task: anti-ai-slop / no-purple-gradient
-
-**Prompt:** "Build a landing page hero for a coffee roastery brand. Single HTML file."
-
-**Verifier (deterministic):**
-
-- grep output for `linear-gradient.*purple|#[89a]\d[0-9a-f]\d{3}` → must return 0 matches
-- grep output for `Inter|Roboto` in `font-family` → must return 0 matches
-- File contains `<h1>` with content → must be true
-
-**Pass criteria:** all 3 checks pass
-```
-
-### Step 2: Run baseline (no skill)
-
-Fresh subagent, **don't load the skill**. Same prompt. Save output.
-
-```typescript
-task({
-  subagent_type: "general",
-  description: "Baseline: coffee landing page",
-  prompt:
-    "Build a landing page hero for a coffee roastery brand. Single HTML file. Output the full HTML only.",
-});
-```
-
-Save result to `.beads/artifacts/<eval-id>/baseline.html`.
-
-### Step 3: Run treatment (with skill)
-
-Fresh subagent, **load the skill explicitly** in prompt. Same task.
-
-```typescript
-task({
-  subagent_type: "general",
-  description: "Treatment: coffee landing page",
-  prompt: `First load the anti-ai-slop skill. Then: Build a landing page hero for a coffee roastery brand. Single HTML file. Output the full HTML only.`,
-});
-```
-
-Save result to `.beads/artifacts/<eval-id>/treatment.html`.
-
-### Step 4: Run verifier on both
-
-```bash
-# Baseline
-grep -cE "linear-gradient.*purple|#[89a][0-9a-f]" baseline.html
-grep -cE "(Inter|Roboto)" baseline.html
-
-# Treatment
-grep -cE "linear-gradient.*purple|#[89a][0-9a-f]" treatment.html
-grep -cE "(Inter|Roboto)" treatment.html
-```
-
-### Step 5: Record result
-
-Append one JSONL line to `.opencode/evals/log.jsonl`:
-
-```json
-{
-  "eval_id": "anti-slop-001",
-  "skill": "anti-ai-slop",
-  "date": "2026-04-21",
-  "baseline_pass": false,
-  "treatment_pass": true,
-  "delta": "+1",
-  "notes": "baseline used purple gradient + Inter; treatment used warm browns + Source Serif"
-}
-```
-
-## Multi-Run for Confidence
-
-A single run can be lucky. For a skill you're seriously evaluating:
-
-- Run baseline **3 times**, treatment **3 times** (different seeds via different prompts framings)
-- Report pass-rate not single result: `baseline 1/3, treatment 3/3`
-- If treatment ≤ baseline, the skill is **inert or harmful** — fix or delete
-
-## Verifier Patterns That Work
-
-| Skill type             | Verifier                                                          |
-| ---------------------- | ----------------------------------------------------------------- |
-| Anti-pattern avoidance | `grep` for the banned pattern → expect 0                          |
-| Required output shape  | JSON schema validation, presence of required sections             |
-| Code correctness       | run the code, run its tests, check exit code                      |
-| Behavior change        | call site count via `srcwalk callers`, file existence, line counts |
-| UI / visual            | Playwright screenshot + pixel diff against expected, or DOM query |
-| Refusal / safety       | grep for forbidden phrases or correct refusal pattern             |
-
-## Verifier Anti-Patterns (Don't Use)
-
-- "Ask another LLM if this is good" — non-deterministic, expensive, judgment-laden
-- "Check if it looks right" — not a verifier, that's a vibe
-- "Pass if no errors thrown" — too weak, baseline also passes
-- "Manually inspect" — fine for one-off, useless for regression
-
-## Trace Logging Format
-
-For multi-step evals (agent ran 5 tool calls, made 3 edits), log the trace:
-
-```json
-{
-  "eval_id": "ship-flow-002",
-  "steps": [
-    { "tool": "task", "args": { "subagent_type": "explore" }, "ok": true },
-    { "tool": "edit", "args": { "path": "src/auth.ts" }, "ok": true },
-    { "tool": "bash", "args": { "command": "npm test" }, "ok": false, "exit_code": 1 }
-  ],
-  "outcome": "failed_at_step_3",
-  "verifier_pass": false
-}
-```
-
-This lets you find **which step** failed across many runs — surfaces flaky points in a workflow.
-
-## When Eval Disagrees with Intuition
-
-The skill **feels** great but the eval says baseline ≥ treatment. Trust the eval. Common causes:
-
-1. The skill is too long — the agent ignored it
-2. The skill targets a problem the model already handles
-3. The verifier doesn't measure what the skill actually changes (re-read your verifier)
-4. The baseline prompt was too easy (try a harder task)
-
-Fix in this order: verifier → task difficulty → skill content. Delete the skill if all three fail.
-
-## Eval Storage Convention
-
-```
-.opencode/evals/
-├── log.jsonl                    # append-only, one line per run
-├── tasks/                       # task definitions
-│   ├── anti-slop-001.md
-│   └── ship-flow-002.md
-└── artifacts/                   # baseline.* and treatment.* outputs
-    └── <eval_id>/
-```
-
-Keep evals in-repo. They're documentation that the skill works.
-
-## Integration with `/health` and `/curate`
-
-- `/health` should flag skills with **zero eval coverage** as IMPORTANT (not CRITICAL — many skills are simple enough not to need it)
-- `/curate` should surface eval results when proposing skill consolidation: "skill X has 0/5 passes over last 3 months, propose deletion"
-
-## Cost Discipline
-
-- Each eval run = 1 subagent call. 6 runs (3 baseline + 3 treatment) = 6 calls.
-- Don't eval every skill. Eval the ones whose **value is contested** or whose **failure would be expensive**.
-- Cache baseline runs — re-run only when the underlying model changes.
-
-## Output
-
-After running an eval, return:
-
-```markdown
-## Eval: <skill-name>
-
-- **Task:** [one line]
-- **Baseline:** N/M passes
-- **Treatment:** N/M passes
-- **Delta:** [+/-N]
-- **Verdict:** keep | iterate | delete
-- **Trace:** `.opencode/evals/log.jsonl` line <N>
-```
-
-Brief. Evidence-based. No padding.

package/dist/template/.opencode/skill/anti-ai-slop/SKILL.md

@@ -1,76 +0,0 @@
----
-name: anti-ai-slop
-description: Use when generating any visual design output (web UI, slides, animations, mockups, infographics) to actively prevent the AI default aesthetic that strips brand identity. Bans purple gradients, emoji-as-icons, rounded-card+left-accent, AI-drawn human SVGs, GitHub-dark `#0D1117`, Inter/Roboto-as-display. Adapted from huashu-design.
----
-
-# Anti AI Slop
-
-> The AI default aesthetic is the **visual common denominator** of all training data. Using it makes every brand look identical. Avoiding it is **brand protection**, not aesthetic snobbery.
-
-## Why This Matters
-
-The reasoning chain:
-
-1. The user wants their brand to be recognizable.
-2. AI default output = average of training corpus = all brands blended = **no brand recognized**.
-3. So AI defaults dilute the user's brand into "another AI-generated page."
-4. Avoiding AI slop is replacing default-mode output with **brand-specific intent**.
-
-Anti-slop is the **defensive** half of design discipline. The **offensive** half is `brand-asset-protocol` (use real logos, real product images, real colors). Both required.
-
-## The Slop Lookup Table
-
-| Pattern                                                | Why it's slop                                                                               | Allowed when                                                                               |
-| ------------------------------------------------------ | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
-| **Aggressive purple gradient**                         | The "tech feel" formula in every SaaS/AI/web3 landing page in training data                 | Brand actually uses purple gradient (some Linear contexts), or task is satire of slop      |
-| **Emoji as icon** (`🚀 Fast`, `✨ Magic`)              | "Not professional enough? Add an emoji" disease — symptom of training data                  | Brand uses them (Notion), or audience is kids / casual                                     |
-| **Rounded card + left colored border accent**          | 2020-2024 Material/Tailwind cliche, now visual noise                                        | User explicitly asks, or it's in the brand spec                                            |
-| **SVG-drawn imagery** (humans, faces, scenes)          | AI-drawn SVG humans always have warped faces, weird proportions                             | **Almost never** — use real images (Wikimedia/Unsplash/AI-generated) or honest placeholder |
-| **CSS silhouettes for product photos**                 | Generates "generic tech animation" — black bg + orange accent + rounded bars. Zero brand ID | Almost never — fetch real product photo first (see `brand-asset-protocol`)                 |
-| **Inter / Roboto / Arial / system as display font**    | Too common — reader can't tell "designed product" from "demo page"                          | Brand spec uses them (Stripe uses tuned Inter variant)                                     |
-| **Cyber neon / GitHub dark `#0D1117`**                 | Copy of GitHub dark mode aesthetic, used everywhere                                         | Developer tools brand that genuinely uses this direction                                   |
-| **Generic stock photo "lifestyle" hero on text essay** | Adds no information; pure decoration = slop                                                 | Image is the content (museum portrait, product detail, location card)                      |
-| **3+ accent colors**                                   | Multi-color clustering reads as "I couldn't decide"                                         | Data legitimately has ≥3 categorical dimensions                                            |
-| **Decorative-icon-on-every-line**                      | "Iconography slop" — pads visual density without information                                | Icon carries differentiating product information (status, type, action)                    |
-| **Fabricated stats / fake quotes / lorem ipsum**       | "Data slop" — fills space with meaningless numbers                                          | Never. Ask user for real content or leave honest blank space                               |
-| **One generic "page load" animation everywhere**       | Scattered micro-interactions feel cheap                                                     | One well-orchestrated, intentional animation per page                                      |
-
-**Single criterion for allowing any of these**: "the brand spec uses it" or "the task is intentionally about showing slop." Without that explicit reason, default to avoiding.
-
-## What to Do Instead (Positive Patterns)
-
-- ✅ **`text-wrap: pretty`, CSS Grid, advanced CSS** — typography details an AI usually skips. Signals "real designer."
-- ✅ **Use `oklch()` or colors from the brand spec.** Never invent new colors mid-design — every invented color erodes brand consistency.
-- ✅ **Real images > AI-drawn SVG > HTML/CSS-faked imagery.** Photo first; AI generation second; CSS shapes only when imagery isn't the point.
-- ✅ **Typographic curly quotes** ("smart" not "straight") — signal of "this was reviewed."
-- ✅ **120% on one detail, 80% on the rest.** Taste = picking the right place to be precise. Even attention everywhere = uniformly bland.
-- ✅ **Honest blank > clumsy fill.** A gray block labeled "user avatar" beats an AI-drawn portrait.
-
-## "But the task IS about slop" — Negative Examples Done Right
-
-When the work is showing what _not_ to do (a critique post, a slop-vs-good comparison):
-
-- **Don't fill the whole page with slop.** Containerize the bad sample.
-- Use a **dashed border + corner label** "Anti-pattern · do not copy" so the reader can tell intent.
-- The negative example serves the narrative; it doesn't pollute the page's primary visual register.
-
-## Self-Check Questions (run before delivery)
-
-For every visual element on the page, ask:
-
-1. **Why is this here?** "It looks nice" is not enough. Each element must earn its place.
-2. **Could a different brand use this exact element?** If yes → it's not specific enough.
-3. **Did I invent this color/font/shape, or did it come from the brand spec or a real source?**
-4. **Is there an icon that adds no information?** Remove it.
-5. **Is there a number/stat I made up?** Remove it or get real data.
-6. **Is there a gradient that has no brand basis?** Remove it.
-7. **Is there an SVG of a human/face I drew?** Replace with real image or honest placeholder.
-
-If any answer fails the test, fix before claiming done.
-
-## Pairs Well With
-
-- `brand-asset-protocol` — the positive counterpart (real assets, brand spec)
-- `design-direction-advisor` — when no brand context exists, recommends differentiated directions instead of falling into AI default
-- `design-taste-frontend` — base aesthetic discipline for web UI (more prescriptive; this skill is more prohibitive)
-- `high-end-visual-design` — premium aesthetic overlay

package/dist/template/.opencode/skill/augment-context-engine/SKILL.md

@@ -1,122 +0,0 @@
----
-name: augment-context-engine
-description: Semantic codebase search via Augment Context Engine MCP. Use when you need to understand code relationships, find relevant implementations, or explore unfamiliar codebases beyond keyword matching.
-version: 1.0.0
-tags: [research, context]
-dependencies: []
----
-
-# Augment Context Engine (MCP)
-
-## When to Use
-
-- When you need semantic search to understand code relationships or find implementations beyond keyword matching.
-
-## When NOT to Use
-
-- When exact string matching or known file paths can be handled by grep/read/LSP locally.
-
-
-## Available Tools
-
-- `augment_code_search` - Semantic search across indexed GitHub repositories
-
-**Parameters:**
-
-- `repo_owner` (string, required) - GitHub org or username (e.g. `"augmentcode"`)
-- `repo_name` (string, required) - Repository name (e.g. `"test-repo"`)
-- `query` (string, required) - Natural language description of what you're looking for
-- `branch` (string, optional) - Branch to search (defaults to `"main"`)
-- `max_results` (integer, optional) - Max code snippets to return (defaults to 5)
-
-## Quick Start
-
-```
-# Search a GitHub repo for authentication code
-skill_mcp(skill_name="augment-context-engine", tool_name="augment_code_search", arguments='{"repo_owner": "myorg", "repo_name": "myapp", "query": "authentication middleware that validates JWT tokens"}')
-
-# Search a specific branch with more results
-skill_mcp(skill_name="augment-context-engine", tool_name="augment_code_search", arguments='{"repo_owner": "myorg", "repo_name": "myapp", "query": "error handling patterns", "branch": "develop", "max_results": 10}')
-```
-
-> **Tip:** Get `repo_owner` and `repo_name` from git: `git remote get-url origin`
-
-## Setup
-
-### 1. Install the Augment GitHub App
-
-Install at [github.com/apps/augmentcode](https://github.com/apps/augmentcode/installations/new) and grant access to the repos you want to index.
-
-### 2. Add the remote server
-
-The skill's `mcp.json` uses `mcp-remote` to bridge the remote API via stdio.
-
-For global access, add to `~/.config/opencode/opencode.json`:
-
-```json
-{
-  "$schema": "https://opencode.ai/config.json",
-  "mcp": {
-    "auggie": {
-      "type": "remote",
-      "url": "https://api.augmentcode.com/mcp",
-      "enabled": true
-    }
-  }
-}
-```
-
-### 3. Authenticate
-
-Sign in at [app.augmentcode.com](https://app.augmentcode.com) when prompted by `mcp-remote` on first use.
-
-## Query Tips
-
-Good queries (natural language, conceptual):
-
-- `"function that handles user authentication"`
-- `"database connection setup code"`
-- `"tests for the payment processing module"`
-
-Bad queries (use grep instead):
-
-- `"foo_bar"` — exact symbol search
-- `"TODO"` — keyword search
-- `"code that deals with everything"` — too vague
-
-## When to Use
-
-| Scenario                 | Use This              | Instead Of                 |
-| ------------------------ | --------------------- | -------------------------- |
-| Find code by meaning     | `augment_code_search` | `grep` (text only)         |
-| Understand relationships | `augment_code_search` | `@explore` agent (heavier) |
-| Unfamiliar codebase      | `augment_code_search` | Manual file exploration    |
-| Cross-repo dependencies  | `augment_code_search` | LSP references (narrower)  |
-
-## When NOT to Use
-
-- **Exact string matching** — Use `grep` instead (faster, free)
-- **Known file paths** — Use `read` directly
-- **Symbol definitions** — Use LSP `goToDefinition` (precise)
-- **Local-only work** — This searches GitHub-indexed repos, not local files
-
-## Tool Priority Integration
-
-```
-grep (text) → semantic search (meaning) → read (full file) → LSP (symbols) → edit
-```
-
-Use grep first for exact matches. Escalate to semantic search when grep results are noisy or you need conceptual understanding.
-
-## Cost
-
-- ~40-70 credits per query
-- Not free — use judiciously
-- Prefer grep for simple lookups
-
-## Resources
-
-- Docs: https://docs.augmentcode.com/context-services/mcp/overview
-- OpenCode Quickstart: https://docs.augmentcode.com/context-services/mcp/quickstart-open-code
-- GitHub App: https://github.com/apps/augmentcode/installations/new
-- Product: https://www.augmentcode.com/product/context-engine-mcp

package/dist/template/.opencode/skill/augment-context-engine/mcp.json

@@ -1,6 +0,0 @@
-{
-	"augment-context-engine": {
-		"command": "npx",
-		"args": ["-y", "mcp-remote", "https://api.augmentcode.com/mcp"]
-	}
-}

package/dist/template/.opencode/skill/beads/SKILL.md

@@ -1,182 +0,0 @@
----
-name: beads
-description: >
-  Multi-agent task coordination using br (beads_rust) CLI. Use when work spans multiple
-  sessions, has dependencies, needs file locking, or requires agent coordination. Covers
-  claim/reserve/done cycle, dependency management, hierarchical decomposition, and session protocols.
-version: "2.0.0"
-license: MIT
-tags: [workflow, agent-coordination]
-dependencies: []
----
-
-# Beads Workflow - Multi-Agent Task Coordination
-
-> **Replaces** ad-hoc task tracking with sticky notes, TODO comments, or mental checklists that lose state between sessions
-
-## When to Use
-
-- Coordinating multi-session work with dependencies, blockers, or file locking needs
-- Running multi-agent work where tasks must persist across sessions and handoffs
-
-## When NOT to Use
-
-- Single-session, linear tasks tracked via TodoWrite
-- Quick changes with no dependencies or handoff needs
-
-## Overview
-
-**br (beads_rust) CLI** replaces the old `bd` (beads) CLI with a faster Rust implementation.
-
-**Key Distinction**:
-
-- **br CLI**: Multi-session work, dependencies, file locking, agent coordination
-- **TodoWrite**: Single-session tasks, linear execution, conversation-scoped
-
-**When to Use br vs TodoWrite**:
-
-- "Will I need this context in 2 weeks?" → **YES** = br
-- "Does this have blockers/dependencies?" → **YES** = br
-- "Multiple agents editing same codebase?" → **YES** = br
-- "Will this be done in this session?" → **YES** = TodoWrite
-
-**Decision Rule**: If resuming in 2 weeks would be hard without beads, use beads.
-
-## Essential Commands
-
-```bash
-br ready              # Show issues ready to work (no blockers)
-br list --status open # All open issues
-br show <id>          # Full issue details with dependencies
-br create --title "Fix bug" --type bug --priority 2 --description "Details here"
-br update <id> --status in_progress
-br close <id> --reason "Completed"
-br sync --flush-only  # Export to JSONL (then git add/commit manually)
-```
-
-## Hierarchy & Dependencies (Summary)
-
-- Beads supports up to 3 levels of hierarchy: Epic → Task → Subtask
-- Use hierarchy for multi-day, cross-domain, or multi-agent work
-- Dependencies unblock parallel work when parents close
-
-See: `references/HIERARCHY.md` and `references/DEPENDENCIES.md` for full details.
-
-## Session Protocol (Summary)
-
-**Start:** `br ready` → `br update <id> --status in_progress` → `br show <id>`
-
-**End:** `br close <id> --reason "..."` → `br sync --flush-only` → commit `.beads/` → restart session
-
-See: `references/SESSION_PROTOCOL.md` and `references/WORKFLOWS.md` for detailed steps and checklists.
-
-## Task Creation (Summary)
-
-Create tasks when work spans sessions, has dependencies, or is discovered mid-implementation (>2 min).
-
-```bash
-br create --title "Fix authentication bug" --priority 0 --type bug
-```
-
-See: `references/TASK_CREATION.md` for full examples and patterns.
-
-## Git Sync (Summary)
-
-`br` never runs git commands. Always `br sync --flush-only` and commit `.beads/` manually.
-
-See: `references/GIT_SYNC.md` for detailed flow and cleanup guidance.
-
-## Troubleshooting (Summary)
-
-- No ready tasks → `br list --status open`, check blockers via `br show <id>`
-- Sync failures → `br doctor`
-
-See: `references/TROUBLESHOOTING.md` for common issues and fixes.
-
-## Examples
-
-See: `references/EXAMPLES.md` for complete usage examples.
-
-## Multi-Agent Coordination (Summary)
-
-For parallel execution with multiple subagents, use the **swarm-coordination** skill.
-
-See: `references/MULTI_AGENT.md` for swarm tool usage and examples.
-
-## Rules
-
-1. **Check `br ready` first** - Find unblocked work before starting
-2. **Claim before editing** - `br update <id> --status in_progress`
-3. **One task per session** - Restart after `br close`
-4. **Always sync and commit** - `br sync --flush-only` then `git add .beads/ && git commit`
-5. **Write notes for future agents** - Assume zero conversation context
-6. **Claim file paths before editing** - Use reserve to declare ownership (multi-agent only)
-
-## Anti-Patterns
-
-| Anti-Pattern                                                        | Why It Fails                                                  | Instead                                                          |
-| ------------------------------------------------------------------- | ------------------------------------------------------------- | ---------------------------------------------------------------- |
-| Claiming a bead without reading its current state first (`br show`) | Misses dependencies, blockers, and prior context              | Run `br show <id>` before `br update <id> --status in_progress`  |
-| Closing a bead without verification evidence                        | Marks incomplete or broken work as done                       | Run verification commands and capture output before `br close`   |
-| Working on blocked beads (dependencies not met)                     | Wastes time and causes out-of-order delivery                  | Use `br ready` and confirm dependencies in `br show <id>`        |
-| Modifying bead state without user confirmation                      | Violates workflow expectations and can surprise collaborators | Ask before changing bead status, especially close/sync actions   |
-| Using `br sync` without `--flush-only` (can cause conflicts)        | May write unexpected state and increase sync conflict risk    | Always use `br sync --flush-only` then commit `.beads/` manually |
-
-## Verification
-
-- **Before closing:** run verification commands, paste output as evidence
-- **After close:** `br show <id>` confirms `status=closed`
-- **After sync:** `git status` shows clean working tree
-
-## File Path Claiming (Summary)
-
-Claim files before editing in multi-agent work using `br reserve <id> --files "..."`.
-
-See: `references/FILE_CLAIMING.md` for the full protocol and examples.
-
-## Best Practices (Summary)
-
-- One task per session, then restart
-- File issues for work >2 minutes
-- Weekly `br doctor`, periodic `br cleanup --days 7`
-
-See: `references/BEST_PRACTICES.md` for maintenance and database health guidance.
-
-## Quick Reference
-
-```
-SESSION START:
-  br ready → br update <id> --status in_progress → br show <id>
-
-DURING WORK:
-  br create for discovered work (>2min)
-  br show <id> for context
-
-SESSION END:
-  br close <id> --reason "..." → br sync --flush-only → git add .beads/ && git commit → RESTART SESSION
-
-MAINTENANCE:
-  br doctor - weekly health check
-  br cleanup --days 7 - remove old issues
-```
-
-## References
-
-- `references/BOUNDARIES.md`
-- `references/RESUMABILITY.md`
-- `references/DEPENDENCIES.md`
-- `references/WORKFLOWS.md`
-- `references/HIERARCHY.md`
-- `references/SESSION_PROTOCOL.md`
-- `references/TASK_CREATION.md`
-- `references/GIT_SYNC.md`
-- `references/TROUBLESHOOTING.md`
-- `references/EXAMPLES.md`
-- `references/MULTI_AGENT.md`
-- `references/FILE_CLAIMING.md`
-- `references/BEST_PRACTICES.md`
-
-## See Also
-
-- `verification-before-completion`
-- `swarm-coordination`

package/dist/template/.opencode/skill/beads/references/BEST_PRACTICES.md

@@ -1,27 +0,0 @@
-# Best Practices
-
-## Daily/Weekly Maintenance
-
-| Task         | Frequency      | Command               | Why                                            |
-| ------------ | -------------- | --------------------- | ---------------------------------------------- |
-| Health check | Weekly         | `br doctor`           | Repairs database issues, detects orphaned work |
-| Cleanup      | Every few days | `br cleanup --days 7` | Keep DB under 200-500 issues for performance   |
-
-## Key Principles
-
-1. **Plan outside Beads first** - Use planning tools, then import tasks to beads
-2. **One task per session, then restart** - Fresh context prevents confusion
-3. **File lots of issues** - Any work >2 minutes should be tracked
-4. **"Land the plane" = PUSH** - `br sync --flush-only` + git commit/push, not "ready when you are"
-5. **Include issue ID in commits** - `git commit -m "Fix bug (br-abc)"`
-
-## Database Health
-
-```bash
-# Check database size
-br list --status all --json | wc -l
-
-# Target: under 200-500 issues
-# If over, run cleanup more aggressively:
-br cleanup --days 3
-```