aicoder-opencode

Use when asked to work in a continuous loop until done or truly blocked. Orchestrates pickup, planning, TDD execution, implementation waves when needed, debugging side-chains, verification, and resume behavior.

Use before planning when a feature or change request is underspecified. Resolve high-impact ambiguity around scope, consumers, security, failure handling, and acceptance criteria before writing the implementation plan.

Use for both preparing work for review and responding to review feedback. Keep review evidence local, concrete, and scoped to the real contract. Verify technically before agreeing or changing code.

Use before implementation. Merge design discovery and plan writing into one DR-specific flow: identify the consumer, inspect the repo, debate boundaries with partner and combatant, and produce an execution-ready plan that hands off cleanly into DR-native tasks, TDD, and implementation waves.

Use for the last mile: rerun verification, inspect diffs, commit or push if requested, and perform local docker-compose checks when needed. This is the DR local-tools replacement for MCP-style finish/deploy carryovers.

Use after planning and before implementation when you need a concrete, dependency-ordered task list. Turn the DR feature spec and plan into independently testable task slices with exact file paths and verification commands.

Use when resuming work in this repo after a pause or starting a fresh session on in-flight changes. Reconstruct the current state, open risks, relevant files, completed verification, and next actions.

Use for any repo behavior change. Purpose and consumer first, failing test before code, then component-appropriate lint, build, and evidence. Hand off to implementation waves only when the slice is too broad for one focused change.

Use for bugs, failing tests, bad runtime behavior, or unexpected regressions. Gather evidence locally, identify root cause, then fix and verify through the correct component commands.

Use when executing a non-trivial DR implementation plan across multiple files or independent slices. Run implementation in bounded waves, review each wave before the next, and keep local-tool verification explicit.

Shared development doctrine for aicoder-opencode and its target repos — plugin ownership, overlay split, shared base vs product boundaries

Shared maintenance topology and policy for aicoder-opencode — one server per repo, shared plugins, overlay-first changes

Triage a stalled aicoder-opencode server, dr-repo autopilot loop, or child tool process — decide whether it is working, waiting, blocked, or dead before signalling anything

Post-implementation review — launch three parallel reviewers (reuse, quality, efficiency) over recent control-plane changes and synthesize a ranked fix list

Use when changing config/models.jsonc — tier policy, role assignments, provider routing, cost/quota visibility. Do not use for target registry or overlay changes.

Use when adding or modifying targets in config/targets/ or their overlays in targets/. Do not use for model registry or plugin changes.

Use whenever work touches dr-agent. Encodes the Windows-only build, lint, test, and design constraints that are easy to miss from a Linux workstation.

Use for portal-heavy work: Gin handlers, middleware, templates, SSE flows, dashboard pages, auth, sessions, CSRF wiring, and user-visible portal behavior.

Use when the goal is to drive the repo toward production readiness instead of just passing one local slice. Enforces cross-component release gates, rollout prerequisites, and evidence for a real ship decision.

Use when you need the shared DR Platform reference: component verification commands, known repo risk areas, Windows-agent rules, portal checks, and security expectations.

Use for security-sensitive changes or reviews. Focus on injection, auth, session handling, auditability, sensitive logging, and the repo’s required adversarial test posture.

Use when work spans multiple letta-workspace subprojects or requires understanding cross-subproject dependencies. Do not use for single-subproject changes.

Harvest learnings from target sessions and promote proven overlay patterns to the shared control-plane base

Self-health check, doom-loop recovery, and patch propagation workflow for the aicoder-opencode control plane