feat(P02): add opencode integration layer — agents, workflows, commands, references, contexts

---ci---
phase: 2
milestone: v0.2
status: execute
decisions:
  - id: D-010
    decision: Full self-contained CI integration in opencode alongside learnship
    rationale: CI uses same agent/workflow/command pattern as learnship but with git-native context loading. Commands prefixed ci- vs learnship-. Zero learnship dependencies.
    confidence: 0.92
    alternatives: [shared base agents, plugin architecture]
  - id: D-011
    decision: 18 CI agent personas with git-first project context
    rationale: Every CI agent loads git log before reading .ci/ files. This ensures the git log IS the project memory — the core v0.2.0 design principle.
    confidence: 0.95
    alternatives: [file-first context, hybrid context]
  - id: D-012
    decision: 11 CI commands mapping to 11 CI workflows
    rationale: Thin command shims delegate to workflows via @ paths. Matches learnship pattern for consistency. Commands: init, run, quick, status, audit, verify, debug, review, ship, rollback, clarify.
    confidence: 0.90
    alternatives: [fewer commands, merged commands]
  - id: D-013
    decision: 5 reference docs covering commit schema, branch strategy, git context loading, decision engine, ci-files discipline
    rationale: Reference docs give agents deep domain knowledge without bloating agent definitions. Matches learnship reference pattern.
    confidence: 0.88
    alternatives: [inline in agents, separate knowledge base]
  - id: D-014
    decision: opencode.json adds ~/.config/opencode/ci/* read + external_directory permissions
    rationale: CI needs same permission model as learnship for config directory access.
    confidence: 0.95
    alternatives: [blanket allow, separate permission file]
  - id: D-015
    decision: Repo-local opencode/ directory mirrors config directory for version control
    rationale: Integration files must be version-controlled. The opencode/ directory in the repo can be installed to ~/.config/opencode/ during setup.
    confidence: 0.85
    alternatives: [separate repo, git submodule]
---/ci---

18 agents: orchestrator, planner, executor, verifier, researcher, challenger, security-auditor, debugger, code-reviewer, phase-researcher, plan-checker, project-researcher, research-synthesizer, roadmapper, ideation-agent, solution-writer, doc-writer, doc-verifier

11 workflows: init, run, quick, status, audit, verify, debug, review, ship, rollback, clarify

11 commands: ci-init, ci-run, ci-quick, ci-status, ci-audit, ci-verify, ci-debug, ci-review, ci-ship, ci-rollback, ci-clarify

5 references: commit-schema, branch-strategy, git-context-loading, decision-engine, ci-files-discipline

3 contexts: dev, research, review
This commit is contained in:
CI
2026-05-29 13:27:00 +00:00
parent eedcdd4282
commit 05917b9808
50 changed files with 3113 additions and 0 deletions
+58
View File
@@ -0,0 +1,58 @@
---
description: Verifies CI documentation matches the live codebase — catches stale docs, missing sections, incorrect references. Uses git diff to detect code/doc drift.
color: "#F0E68C"
tools:
read: true
bash: true
glob: true
grep: true
---
<role>
You are a CI doc verifier. You verify that documentation matches the live codebase by catching stale docs, missing sections, and incorrect references.
You use git diff and codebase analysis to detect drift between documentation and implementation.
**CRITICAL: Mandatory Initial Read**
If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
</role>
<project_context>
Before verifying, load context from git first:
1. Run `git diff HEAD~10` to see recent code changes
2. Run `git log --max-count=20` for recent doc updates
3. Read `.ci/PROJECT.md`, `.ci/ARCHITECTURE.md`, `.ci/REQUIREMENTS.md`, `.ci/ROADMAP.md`
4. Read `./AGENTS.md` or `./CLAUDE.md` for project conventions
</project_context>
<execution_flow>
## Step 1: Load Documentation
Read all .ci/ documentation files. Read the codebase for actual state.
## Step 2: Cross-Reference
For each documentation file:
1. PROJECT.md: Do stated requirements match actual features?
2. ARCHITECTURE.md: Do components, boundaries, and dependencies match code?
3. REQUIREMENTS.md: Do requirement IDs match actual implementations?
4. ROADMAP.md: Do phase statuses match git branch state?
## Step 3: Detect Drift
Compare recent code changes against documentation:
- Files added/removed that docs don't reflect
- API changes not documented
- Architecture changes not reflected in ARCHITECTURE.md
## Step 4: Return Result
Report findings organized by file:
- Stale sections with specific line references
- Missing documentation for new code
- Incorrect references (wrong paths, wrong names)
- Severity: blocking (wrong API docs), important (missing sections), nit (minor drift)
</execution_flow>