-
Notifications
You must be signed in to change notification settings - Fork 25
Description
Feature request: Pluggable agent support (Codex CLI, opencode, and beyond)
Summary
Chief's orchestration logic — the Ralph loop, task queue, git workflow, TUI — is inherently agent-agnostic. The only tight coupling today is the hardcoded calls to the claude binary. Introducing a thin Provider abstraction would let users choose their preferred AI coding agent while keeping Claude Code as the default with zero breaking changes.
The first alternative target is OpenAI Codex CLI; the architecture should make it straightforward to add others like opencode later.
Motivation
- Some teams or individuals already use Codex CLI or are experimenting with alternatives like opencode
- Chief's value lies in the orchestration layer (PRD → stories → autonomous loop → commits), not in a specific LLM backend
- A pluggable architecture makes the project more tool-agnostic, broadens its audience, and invites contributions for new runners
Proposed approach
Interface — A Provider interface in internal/loop/provider.go:
type Provider interface {
Name() string
CLIPath() string
LoopCommand(ctx context.Context, prompt, workDir string) *exec.Cmd
InteractiveCommand(workDir, prompt string) *exec.Cmd
ConvertCommand(workDir, prompt string) (cmd *exec.Cmd, mode OutputMode, outPath string, err error)
FixJSONCommand(prompt string) (cmd *exec.Cmd, mode OutputMode, outPath string, err error)
ParseLine(line string) *Event
LogFileName() string
}Each agent CLI has different flags, output formats, and conventions. The interface captures the four interaction modes Chief needs (autonomous loop, interactive session, one-shot conversion, JSON fix) plus a per-provider JSONL parser that maps agent-specific events to Chief's internal Event types.
Implementations in internal/agent/:
ClaudeProvider— current behaviour, wraps theclaudebinaryCodexProvider— wrapscodex exec --json --yolofor the loop,codex exec --output-last-message -o <file>for one-shot tasks
Configuration — three layers, in priority order:
# CLI flag
chief --agent codex --agent-path /usr/local/bin/codex
# Environment variable
CHIEF_AGENT=codex CHIEF_AGENT_PATH=/usr/local/bin/codex chief
# .chief/config.yaml
agent:
provider: codex
cliPath: /usr/local/bin/codex # optionalResolution centralised in agent.Resolve(): flag → env → config → default (claude). Unknown provider names return an explicit error.
Non-goals / guarantees
- Claude Code remains the default — zero impact on existing users and configs
- No changes to the PRD format, story structure, prompt templates, or TUI behaviour
- Each provider implementation is responsible for mapping its own CLI flags and output format; the rest of Chief stays untouched
- The
<chief-complete/>/<ralph-status>protocol lives in the shared prompt, not in provider code — any agent that follows instructions will produce the right markers
Future runners
Once the abstraction is in place, adding a new agent is a contained task:
- Create
internal/agent/<name>.goimplementingProvider(~70 lines) - Create
internal/loop/<name>_parser.gomapping the agent's JSONL to Chief events (~100 lines) - Add one
caseinagent.Resolve()
No other file needs modification. Potential candidates:
- opencode — open-source, multi-model
- Any future CLI-based coding agent
Implementation
I have a working implementation ready with full test coverage. Happy to open a PR if this direction aligns with the project's vision — or to discuss the interface design first if you'd prefer.