docs: document OpenCode agents research
- Built-in agents: Build (full access) and Plan (read-only) - Custom agents support prompts, model overrides, tool control - Skills are global, agents access via skill() tool - Permission control per-agent via opencode.json - OpenCode supports Claude-compatible skill paths Closes skills-czz 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
dan
parent
b1cb619f7a
commit
3ca79bb3bd
|
|
@ -42,12 +42,12 @@
|
|||
{"id":"skills-cc0","title":"spec-review: Add anti-hallucination constraints to prompts","description":"Models may paraphrase and present as quotes, or invent requirements/risks not in the doc.\n\nAdd:\n- 'Quotes must be verbatim'\n- 'Do not assume technologies/constraints not stated'\n- 'If missing info, list as open questions rather than speculating'","status":"closed","priority":3,"issue_type":"task","created_at":"2025-12-15T00:23:26.045478292-08:00","updated_at":"2025-12-15T14:07:19.556888057-08:00","closed_at":"2025-12-15T14:07:19.556888057-08:00"}
|
||||
{"id":"skills-cjx","title":"Create spec-review skill for orch + spec-kit integration","description":"A new skill that integrates orch multi-model consensus with spec-kit workflows.\n\n**Purpose**: Use different models/temps/stances to review spec-kit artifacts before phase transitions.\n\n**Proposed commands**:\n- /spec-review.spec - Critique current spec for completeness, ambiguity, gaps\n- /spec-review.plan - Evaluate architecture decisions in plan\n- /spec-review.gate - Go/no-go consensus before phase transition\n\n**Structure**:\n```\nskills/spec-review/\n├── SKILL.md\n├── commands/\n│ ├── spec.md\n│ ├── plan.md\n│ └── gate.md\n└── prompts/\n └── ...\n```\n\n**Key design points**:\n- Finds spec/plan files from current branch or specs/ directory\n- Invokes orch with appropriate prompt, models, stances\n- Presents consensus/critique results\n- AI reviewing AI is valuable redundancy (different models/temps/stances)\n\n**Dependencies**:\n- orch CLI must be available (blocked on dotfiles-3to)\n- spec-kit project structure conventions","status":"closed","priority":2,"issue_type":"feature","created_at":"2025-12-14T17:50:13.22879874-08:00","updated_at":"2025-12-15T00:10:23.122342449-08:00","closed_at":"2025-12-15T00:10:23.122342449-08:00"}
|
||||
{"id":"skills-cnc","title":"Add direnv helper for per-repo skill deployment","description":"Create sourceable helper script and documentation for the standard per-repo skill deployment pattern using direnv + nix build.","status":"closed","priority":2,"issue_type":"feature","created_at":"2025-11-30T12:19:20.71056749-08:00","updated_at":"2025-11-30T12:37:47.22638278-08:00","closed_at":"2025-11-30T12:37:47.22638278-08:00"}
|
||||
{"id":"skills-czz","title":"Research OpenCode agents for skill integration","description":"DEPLOYMENT.md:218 has TODO to research OpenCode agents. Need to understand how Build/Plan/custom agents work and whether skills need agent-specific handling.","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-30T11:58:24.855701141-08:00","updated_at":"2025-11-30T11:58:24.855701141-08:00"}
|
||||
{"id":"skills-czz","title":"Research OpenCode agents for skill integration","description":"DEPLOYMENT.md:218 has TODO to research OpenCode agents. Need to understand how Build/Plan/custom agents work and whether skills need agent-specific handling.","status":"in_progress","priority":2,"issue_type":"task","created_at":"2025-11-30T11:58:24.855701141-08:00","updated_at":"2025-12-28T20:46:28.855569325-05:00"}
|
||||
{"id":"skills-d6r","title":"Design: orch as local agent framework","description":"# Orch Evolution: From Consensus Tool to Agent Framework\n\n## Current State\n- `orch consensus` - multi-model queries\n- `orch chat` - single model queries\n- No state, no pipelines, no retries\n\n## Proposed Extensions\n\n### Pipeline Mode\n```bash\norch pipeline config.yaml\n```\nWhere config.yaml defines:\n- Stages (triage → specialists → verify)\n- Routing logic (if triage finds X, run specialist Y)\n- Retry policy\n\n### Evaluate Mode (doc-review specific)\n```bash\norch evaluate doc.md --rubrics=1,4,7 --output=patches/\n```\n- Applies specific rubrics to document\n- Outputs JSON or patches\n\n### Parallel Mode\n```bash\norch parallel --fan-out=5 --template=\"evaluate {rubric}\" rubrics.txt\n```\n- Fan-out to multiple parallel calls\n- Aggregate results\n\n## Open Questions\n1. Does this belong in orch or a separate tool?\n2. Should orch pipelines be YAML-defined or code-defined?\n3. How does this relate to Claude Code Task subagents?\n4. What's the minimal viable extension?\n\n## Context\nEmerged from doc-review skill design - need multi-pass evaluation but don't want to adopt heavy framework (LangGraph, etc.)","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-04T16:06:56.681282678-08:00","updated_at":"2025-12-04T16:44:08.652185174-08:00","closed_at":"2025-12-04T16:44:08.652185174-08:00"}
|
||||
{"id":"skills-d87","title":"orch skill is documentation-only, needs working invocation mechanism","description":"The orch skill provides SKILL.md documentation but no working invocation mechanism.\n\n**Resolution**: Install orch globally via home-manager (dotfiles-3to). The skill documents a system tool, doesn't need to bundle it.\n\n**Blocked by**: dotfiles-3to (Add orch CLI to home-manager packages)","status":"closed","priority":2,"issue_type":"bug","created_at":"2025-12-14T11:54:03.157039164-08:00","updated_at":"2025-12-16T18:45:24.39235833-08:00","closed_at":"2025-12-16T18:45:24.39235833-08:00","close_reason":"Updated docs to use globally installed orch CLI"}
|
||||
{"id":"skills-dnm","title":"Refactor deploy-skill.sh: dedupe injection calls","description":"File: bin/deploy-skill.sh (lines 112-189)\n\nIssues:\n- Three nearly-identical inject_nix_config() calls\n- Only difference is config block content and target file\n- Repeated pattern bloats file\n\nFix:\n- Parameterize inject_nix_config() better\n- Or create config-specific injection functions\n- Reduce duplication\n\nSeverity: MEDIUM","status":"open","priority":3,"issue_type":"task","created_at":"2025-12-24T02:51:01.855452762-05:00","updated_at":"2025-12-24T02:51:01.855452762-05:00"}
|
||||
{"id":"skills-dpw","title":"orch: add command to show available/configured models","description":"## Problem\n\nWhen trying to use orch, you have to trial-and-error through models to find which ones have API keys configured. Each failure looks like:\n\n```\nError: GEMINI_API_KEY not set. Required for Google Gemini models.\n```\n\nNo way to know upfront which models are usable.\n\n## Proposed Solution\n\nAdd `orch models` or `orch status` command:\n\n```bash\n$ orch models\nAvailable models:\n ✓ flash (GEMINI_API_KEY set)\n ✓ gemini (GEMINI_API_KEY set)\n ✗ deepseek (OPENROUTER_KEY not set)\n ✗ qwen (OPENROUTER_KEY not set)\n ✓ gpt (OPENAI_API_KEY set)\n```\n\nOr at minimum, on failure suggest alternatives:\n```\nError: GEMINI_API_KEY not set. Try --model gpt or --model deepseek instead.\n```\n\n## Context\n\nHit this while trying to brainstorm with high-temp gemini - had to try 4 models before realizing none were configured in this environment.","status":"closed","priority":3,"issue_type":"feature","created_at":"2025-12-04T14:10:07.069103175-08:00","updated_at":"2025-12-04T14:11:05.49122538-08:00","closed_at":"2025-12-04T14:11:05.49122538-08:00"}
|
||||
{"id":"skills-e8h","title":"Investigate waybar + niri integration improvements","description":"Look into waybar configuration and niri compositor integration.\n\nPotential areas:\n- Waybar modules for niri workspaces\n- Status indicators\n- Integration with existing niri-window-capture skill\n- Custom scripts in pkgs/waybar-scripts\n\nRelated: dotfiles has home/waybar.nix (196 lines) and pkgs/waybar-scripts/","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-28T20:11:23.115445797-05:00","created_by":"dan","updated_at":"2025-12-28T20:11:23.115445797-05:00"}
|
||||
{"id":"skills-e8h","title":"Investigate waybar + niri integration improvements","description":"Look into waybar configuration and niri compositor integration.\n\nPotential areas:\n- Waybar modules for niri workspaces\n- Status indicators\n- Integration with existing niri-window-capture skill\n- Custom scripts in pkgs/waybar-scripts\n\nRelated: dotfiles has home/waybar.nix (196 lines) and pkgs/waybar-scripts/","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-28T20:11:23.115445797-05:00","created_by":"dan","updated_at":"2025-12-28T20:37:16.465731945-05:00","closed_at":"2025-12-28T20:37:16.465731945-05:00","close_reason":"Moved to dotfiles repo - waybar config lives there"}
|
||||
{"id":"skills-e96","title":"skill: semantic-grep using LSP","description":"Use workspace/symbol, documentSymbol, and references instead of ripgrep.\n\nExample: 'Find all places where we handle User objects but only where we modify the email field directly'\n- LSP references finds all User usages\n- Filter by AST analysis for .email assignments\n- Return hit list for bead or further processing\n\nBetter than regex for Go interfaces, Rust traits, TS types.","status":"open","priority":3,"issue_type":"task","created_at":"2025-12-24T02:29:57.119983837-05:00","updated_at":"2025-12-24T02:29:57.119983837-05:00","dependencies":[{"issue_id":"skills-e96","depends_on_id":"skills-gga","type":"blocks","created_at":"2025-12-24T02:30:06.632906383-05:00","created_by":"daemon"}]}
|
||||
{"id":"skills-ebh","title":"Compare bd-issue-tracking skill files with upstream","description":"Fetch upstream beads skill files and compare with our condensed versions to identify differences","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-03T20:14:07.886535859-08:00","updated_at":"2025-12-03T20:19:37.579815337-08:00","closed_at":"2025-12-03T20:19:37.579815337-08:00"}
|
||||
{"id":"skills-ebl","title":"Benchmark vision model UI understanding","description":"## Goal\nMeasure how well vision models can answer UI questions from screenshots.\n\n## Test cases\n1. **Element location**: \"Where is the Save button?\" → coordinates\n2. **Element identification**: \"What buttons are visible?\" → list\n3. **State detection**: \"Is the checkbox checked?\" → boolean\n4. **Text extraction**: \"What does the error message say?\" → text\n5. **Layout understanding**: \"What's in the sidebar?\" → structure\n\n## Metrics\n- Accuracy: Does the answer match ground truth?\n- Precision: How close are coordinates to actual element centers?\n- Latency: Time from query to response\n- Cost: Tokens consumed per query\n\n## Prompt engineering questions\n- Does adding a grid overlay help coordinate precision?\n- What prompt format gives most actionable coordinates?\n- Can we get bounding boxes vs point coordinates?\n\n## Comparison baseline\n- Manual annotation of test screenshots\n- AT-SPI data (once enabled) as ground truth\n\n## Depends on\n- Test screenshots from real apps\n- Ground truth annotations","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-17T14:13:10.038933798-08:00","updated_at":"2025-12-17T14:13:10.038933798-08:00"}
|
||||
|
|
|
|||
|
|
@ -209,19 +209,38 @@ skills repo (dev) --[copy]--> dotfiles repo (deploy) --[nix]--> runtime
|
|||
|
||||
## OpenCode Agent Functionality
|
||||
|
||||
**From opencode.ai docs** (need to research more):
|
||||
- OpenCode has "agents" concept separate from skills
|
||||
- Agents appear to be different AI personalities/modes
|
||||
- Skills work with all agents
|
||||
- Commands can specify which agent via frontmatter
|
||||
**Built-in agents:**
|
||||
- **Build** - Default primary agent with all tools enabled (file ops, bash, etc.)
|
||||
- **Plan** - Restricted agent for analysis/planning without making changes
|
||||
|
||||
**TODO**: Research OpenCode agents to understand:
|
||||
- What are the available agents?
|
||||
- How do skills interact with agents?
|
||||
- Should skills be agent-specific?
|
||||
- Do we need agent-specific deployment?
|
||||
**Custom agents** can be created with:
|
||||
- Custom system prompts
|
||||
- Model overrides (e.g., faster model for planning)
|
||||
- Tool access control (per-agent tool enable/disable)
|
||||
|
||||
**For now**: Deploy skills globally, they work with all agents.
|
||||
**Skills + Agents interaction:**
|
||||
- Skills are global - all agents see available skills in their tool description
|
||||
- Agents access skills via `skill({ name: "skill-name" })` tool
|
||||
- Permission control per-agent via `opencode.json` or agent frontmatter:
|
||||
```json
|
||||
{
|
||||
"permission": {
|
||||
"skill": {
|
||||
"skill-name": "allow",
|
||||
"pattern-*": "deny",
|
||||
"*": "ask"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Skill discovery paths (searched in order):**
|
||||
- `.opencode/skill/<name>/SKILL.md` (project-local)
|
||||
- `~/.config/opencode/skill/<name>/SKILL.md` (global)
|
||||
- `.claude/skills/<name>/SKILL.md` (Claude-compatible)
|
||||
|
||||
**Conclusion:** Deploy skills globally to `~/.claude/skills/` (works for both Claude Code
|
||||
and OpenCode). No agent-specific deployment needed - use permissions to control access.
|
||||
|
||||
## Current Skills Status
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue