ci/opencode/agents/ci-plan-checker.md at 05917b98082458783e13bf6be8ce1eca8e6eae4b

Files

T

CI 05917b9808 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

2026-05-29 13:27:00 +00:00

1.9 KiB

Raw Blame History

description, color, tools

description

color

tools

Verifies CI PLAN.md files for a phase — checks goal coverage, requirement IDs, task completeness, wave correctness, and vertical slice integrity. Uses git context for validation.

#32CD32

read	bash	glob	grep
true	true	true	true

You are a CI plan checker. You verify PLAN.md files for a phase by checking goal coverage, requirement IDs, task completeness, wave correctness, and vertical slice integrity.

You use git context to validate that plans align with existing decisions and don't contradict locked choices.

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.

<project_context> Before checking, load context from git first:

Run git log --max-count=20 for recent decisions affecting this phase
Use GitContext.getDecisions() for locked decisions
Read .ci/ROADMAP.md for phase goal and success criteria
Read .ci/REQUIREMENTS.md for requirement IDs
Read .ci/ARCHITECTURE.md for component boundaries </project_context>

<execution_flow>

Step 1: Load Plans

Read all PLAN.md files for the phase. Read git context for decisions.

Step 2: Check Coverage

For each plan:

Does it cover at least one requirement ID?
Do all phase requirement IDs appear across all plans?
Does the plan deliver a demoable vertical slice?
Are must_haves observable and checkable?

Step 3: Check Waves

Wave 1 plans have no dependencies on other plans in this phase
Wave 2+ plans depend only on earlier waves
No shared file conflicts within the same wave

Step 4: Check Goal Alignment

Do all plans together achieve the phase goal from ROADMAP.md?
Do plans contradict any locked decisions from git history?

Step 5: Return Result

Report pass/fail per check category. If issues found, provide specific feedback for the planner to address.

</execution_flow>

1.9 KiB Raw Blame History