Co pilot loop

Skill richfrem/agent-plugins-skills/plugins/agent-loops/skills/co-pilot-loop

repo for reusable plugins and skills

Install

npx -y skills add richfrem/agent-plugins-skills --skill co-pilot-loop

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Cooperative Multi-Agent Coordination Loop. Spawns a lightweight companion sub-agent (Gemini 3.5 Flash Low) to perform spec discovery, planning, and implementation. The primary agent (Claude) acts as the QA Director, answering Gemini's questions, approving the spec/plan, and running verification tests. Assumes the superpowers plugin is installed in the target repository.

SKILL.md

5.2 KB, as published. Nobody here has run it

Cooperative Co-Pilot Loop (Supervisor Protocol)

The Co-Pilot Loop splits software engineering tasks between a Supervisor (Outer Loop — you) and an Executor (Inner Loop — a lightweight companion sub-agent). The Supervisor acts as the product manager and QA director, while the Executor performs spec writing, planning, and coding inside an isolated worktree.

You do not know which CLI or chat interface the user is using — and that's fine. The skill is model-agnostic. It reads the cheapest model for the active CLI at runtime.

1. Setup & Orientation

Step 1A — Determine the active CLI backend

Ask the user once (or detect from context):

"Which CLI backend is available for the sub-agent? (agy, claude, copilot, codex, llama)"

Step 1B — Look up the cheapest model for that backend

Read plugins/agent-loops/references/cheapest_models.json (relative to the repo root where this skill is installed). Select the model field for the detected CLI:

CLI	Cheapest Model	Notes
`agy`	`gemini-3.5-flash`	Use `--model "Gemini 3.5 Flash (Low)"` — lower thinking level keeps token costs down
`claude`	`claude-haiku-4.5`	$1/$5 per MTok input/output
`copilot`	`gpt-5.4-nano`	20 cr/1M input, 125 cr/1M output
`codex`	`gpt-5.4-nano`	OpenAI-compatible endpoints
`llama`	`gemma-4-12b`	Free, self-hosted at port 8089

Source of truth: plugins/agent-loops/references/cheapest_models.json. Always read this file — do not hardcode model names. The table above is a snapshot only.

Step 1C — Spawn the sub-agent

Use run_agent.py with the resolved CLI and model:

# For agy (recommended — cheapest Gemini)
python ./scripts/run_agent.py <PERSONA_FILE> <PACKET_FILE> <OUTPUT_FILE> "<INSTRUCTION>" \
  --cli agy --model "Gemini 3.5 Flash (Low)" < /dev/null

# For claude CLI
python ./scripts/run_agent.py <PERSONA_FILE> <PACKET_FILE> <OUTPUT_FILE> "<INSTRUCTION>" \
  --cli claude --model claude-haiku-4.5 < /dev/null

# For copilot CLI
python ./scripts/run_agent.py <PERSONA_FILE> <PACKET_FILE> <OUTPUT_FILE> "<INSTRUCTION>" \
  --cli copilot --model gpt-5.4-nano < /dev/null

CRITICAL: Always append < /dev/null to prevent SIGTTIN process suspension in background execution.

2. Strategy Packet & Handoff

Create an isolated Git worktree or branch for the Executor. Generate a Strategy Packet (via scripts/agent_orchestrator.py packet) containing:

Objective — what feature/bug is being implemented.
Constraints — TDD rules, symlink policy, coding conventions, no deletions.
No-Git Rule — the Executor is strictly forbidden from running any git commands.
Spec output path — e.g. docs/superpowers/specs/YYYY-MM-DD-<feature>-spec.md.
Plan output path — e.g. implementation_plan.md.

Hand the Strategy Packet to the Executor and start the parallel session.

3. Supervision & Review Gates

You (the Supervisor) enforce the following sequential gates. No gate may be skipped.

Gate 1 — Design Spec Review

When the Executor generates a design spec, audit it:

No vague placeholders (TODO, TBD, REPLACE).
Architectural decisions align with existing ADRs and codebase patterns.
Action: Approve → proceed to Gate 2. Reject → pass specific written feedback back to Executor.

Gate 2 — Implementation Plan Review

Review the Executor's implementation_plan.md / task.md:

Files grouped logically by dependency layer.
A clear automated verification plan is included.
Action: Approve → proceed to Gate 3. Reject → return with specific revision notes.

Gate 3 — QA & Verification

Once Executor signals completion, run the verification suite:

python3 run_tests.py    # or npm run test / npm run build
git diff                # inspect all changed files

Classify issues using the severity schema:

🔴 CRITICAL — fails compile or tests. Return error logs to Executor immediately.
🟡 MODERATE — works but violates conventions or ADRs. Return with the specific ADR reference.
🟢 MINOR — stylistic only. Fix directly yourself; do not return to Executor.

Generate correction packets via:

python ./scripts/agent_orchestrator.py correct --packet handoffs/task_packet_NNN.md --feedback "Specific failure reason"

4. Retrospective & Closure

Once all verification tests pass:

Merge the worktree / branch back to main (only from the main repo root, never from inside the worktree).
Update RLM summaries and context files.
git commit the changes.
Write a session retrospective via python ./scripts/agent_orchestrator.py retro.
Capture any prompt template improvements to prevent repeat failures.