agentleFS
dsifrydsifry/metaswarm/skills/external-tools/SKILL.md

external-tools

Skill426 starsChanged 6 months agoMITView on GitHub

Delegate implementation and review tasks to external AI CLI tools (Codex, Gemini) with cross-model adversarial review

  • Installs packages

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. About 0 are common, 9 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    All commands return a uniform JSON envelope with facts only (exit code, files changed, cost, duration).

    line 101
  2. Distinctive:

    Before dispatching any task, the orchestrator runs health checks to determine which tools are available:

    line 109
  3. Distinctive:

    If an external tool is selected as implementer:

    line 129
  4. Very specific:

    If Claude is selected (escalation or no external tools), use the existing Task() mechanism with role type roleType("coder") (adversarial …

    line 137
  5. Distinctive:

    After passing adversarial review:

    line 167
  6. Distinctive:

    Commit with DoD verification in the commit message

    line 172
  7. Distinctive:

    No change to the current workflow.

    line 232
  8. Distinctive:

    If no historical data, prefer Gemini (free tier) over Codex

    line 262
  9. Very specific:

    When an adapter returns exit_code != 0, the error_type field determines the orchestrator's response:

    line 312
  10. Very specific:

    All errors are logged to ~/.claude/sessions/ for self-reflection

    line 330
  11. Distinctive:

    Before each adapter invocation, the orchestrator checks cumulative cost for the current task:

    line 342
  12. Very specific:

    Default: $2.00 per task.

    line 350
  13. Distinctive:

    Before each adapter invocation, the orchestrator checks cumulative cost across all tasks in the session:

    line 354
  14. Very specific:

    Default: $20.00 per session.

    line 363
  15. Very specific:

    All adapter invocations produce structured session log entries in ~/.claude/sessions/:

    line 385

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

External Tools Skill

Purpose

This skill delegates implementation and review tasks to external AI CLI tools (OpenAI Codex CLI, Google Gemini CLI), enabling cost savings through cheaper models and cross-model adversarial review that eliminates single-model blind spots. Three core principles govern every interaction: one job per invocation (an external tool implements OR reviews, never self-validates), minimal permissions (sandboxed execution scoped to the task's working directory with only the tool's own API key), and the orchestrator verifies independently (external tools report facts only, the orchestrator judges pass/fail).


Prerequisites

Required Tools

ToolInstallAuth
OpenAI Codex CLInpm i -g @openai/codexAPI key or ChatGPT subscription
Google Gemini CLInpm i -g @google/gemini-cliGoogle login (free 1K req/day) or API key

Neither tool is strictly required. The skill adapts based on what is available (see Escalation Model below).

Configuration

Per-project config at .metaswarm/external-tools.yaml (optional -- if absent, external tools are not used):

adapters:
  codex:
    enabled: true
    timeout_seconds: 300
    sandbox: docker          # docker | platform | none
  gemini:
    enabled: true
    timeout_seconds: 300
    sandbox: docker

routing:
  default_implementer: "cheapest-available"
  escalation_order: ["codex", "gemini", "claude"]

budget:
  per_task_usd: 2.00        # circuit breaker per task
  per_session_usd: 20.00    # circuit breaker per session

Models are not set here. Set them per role in .metaswarm/models.yaml under roles.<role>.codex or roles.<role>.gemini, and pass --role <role> to the adapter. The model resolves in this order: .metaswarm/models.yaml, then the adapter's built-in default (gpt-5.3-codex for Codex, pro for Gemini). A legacy adapters.<tool>.model in this file is no longer read (removed in 0.14.0); the adapter warns on stderr if one is still present.

Fallback Behavior

  • Both tools available: Full cross-model delegation and review
  • One tool available: Reduced chain with mutual review between the tool and Claude
  • No tools available: Existing metaswarm behavior unchanged; skill is a no-op

Quick Reference

Health Check

# Check if Codex is installed, authenticated, and reachable
adapters/codex.sh health

# Check Gemini, reporting the model for the coder role
adapters/gemini.sh health --role coder

Returns JSON with status: "ready|degraded|unavailable". --role <role> (also accepted by implement and review) selects the model from .metaswarm/models.yaml roles.<role>.<tool>; an unknown role exits non-zero. Without --role, the output keys are unchanged and model is the built-in default. A legacy adapters.<tool>.model is no longer read (removed in 0.14.0), only warned about. The resolved model is passed to the CLI (codex exec -m, gemini --model). If metaswarm-agents.sh cannot be found, --role is ignored with a warning.

Implement

adapters/codex.sh implement \
  --worktree "/tmp/ext-codex-task-42" \
  --prompt-file "/private/tmp/xt-abc123/prompt.md" \
  --role coder \
  --attempt 1 \
  --timeout 300

Review

adapters/gemini.sh review \
  --worktree "/tmp/ext-codex-task-42" \
  --rubric-file "./rubrics/external-tool-review-rubric.md" \
  --spec-file "/private/tmp/xt-abc123/spec.md" \
  --role adversarial-reviewer \
  --timeout 300

All commands return a uniform JSON envelope with facts only (exit code, files changed, cost, duration). The orchestrator interprets results -- adapters never self-judge.


Workflow: Routing & Dispatch

Phase 0: Tool Discovery (Health Checks)

Before dispatching any task, the orchestrator runs health checks to determine which tools are available:

# Run health checks for all configured adapters
for adapter in adapters/*.sh; do
  result=$("$adapter" health)
  # Parse status: ready | degraded | unavailable
done

Health is checked per task dispatch, not just at session start. Auth tokens can expire mid-session, network conditions change, and rate limits reset. A tool that was ready five minutes ago may now be unavailable.

Build the available tools list:

available_tools = [t for t in adapters if t.health() == "ready"]

Phase 1: IMPLEMENT (External Tool or Claude)

If an external tool is selected as implementer:

  1. Create worktree -- git worktree add "$WORKTREE_PATH" -b "external/$TOOL/$TASK_ID" for isolation
  2. Package context -- Gather relevant files, spec, acceptance criteria into a prompt file in a secure temp dir (mode 700, trap cleanup). Token-budget the context to fit the model's window.
  3. Invoke -- safe_invoke() with timeout wrapper; capture JSON output
  4. Scope check -- Verify all file changes are within the declared file scope; revert any out-of-scope changes
  5. Capture output -- Facts only: exit code, files changed, diff stats, cost, duration

If Claude is selected (escalation or no external tools), use the existing Task() mechanism with role type roleType("coder") (adversarial review uses roleType("adversarial-reviewer")). Role types are resolved per Role type resolution.

Phase 2: VALIDATE (Always Orchestrator -- Unchanged)

The orchestrator independently runs all quality gates:

  • npm test / npx vitest run
  • npx tsc --noEmit
  • npx eslint <changed-files>
  • Coverage enforcement via .coverage-thresholds.json
  • File scope verification via git diff --name-only

This phase is identical whether the implementer was an external tool or Claude. Never trust the implementer's self-report.

Phase 3: ADVERSARIAL REVIEW (Cross-Model)

The key advantage of external tools: the writer is always reviewed by a different model.

ImplementerReviewer 1Reviewer 2
CodexGemini (via adapter)Claude (via Task)
GeminiCodex (via adapter)Claude (via Task)
ClaudeCodex (via adapter)Gemini (via adapter)

Claude (via Task) reviewers are spawned as fresh roleType("adversarial-reviewer") instances.

Review is invoked via the adapter's review command. The orchestrator reads the reviewer's raw log and evaluates it independently -- the adapter never returns a pass/fail verdict.

Phase 4: COMMIT (Unchanged)

After passing adversarial review:

  1. Merge the worktree branch into the working branch
  2. Clean up the worktree (git worktree remove)
  3. Log the session for self-reflection
  4. Commit with DoD verification in the commit message

Escalation Model (Availability-Aware)

The orchestrator adapts its escalation chain based on which tools passed their health checks.

Scenario 1: Two External Tools Available (5 attempts max)

Model A implements (attempt 1)
  Orchestrator validates + cross-model review (B + Claude)
  FAIL -> feedback to Model A

Model A implements (attempt 2, with review feedback)
  Orchestrator validates + cross-model review
  FAIL -> escalate to Model B

Model B implements (attempt 1, with Model A's branch as reference)
  Orchestrator validates + cross-model review (A + Claude)
  FAIL -> feedback to Model B

Model B implements (attempt 2, with review feedback)
  Orchestrator validates + cross-model review
  FAIL -> escalate to Claude

Claude implements (with both branches as reference)
  Orchestrator validates + cross-model review (A + B)
  FAIL -> alert user with all branches, findings, CI results

Worst case: A(2) + B(2) + Claude(1) = 5 attempts before user alert.

Scenario 2: One External Tool Available (3 attempts max)

Model A implements (attempt 1)
  Orchestrator validates + review (Claude reviews)
  FAIL -> feedback to Model A

Model A implements (attempt 2, with review feedback)
  Orchestrator validates + review (Claude reviews)
  FAIL -> escalate to Claude

Claude implements (with Model A's branch as reference)
  Orchestrator validates + review (Model A reviews)
  FAIL -> alert user

Worst case: A(2) + Claude(1) = 3 attempts before user alert.

Scenario 3: No External Tools Available

Existing metaswarm behavior unchanged.
Claude implements via Task() mechanism (role type `roleType("coder")`).
Standard adversarial review (fresh Task() instance, role type `roleType("adversarial-reviewer")`).

No change to the current workflow. The skill is a no-op.


Routing Logic

The orchestrator selects the implementer for each task using cheapest-available selection:

available_tools = [t for t in adapters if t.health() == "ready"]

if len(available_tools) == 2:
    implementer = cheapest(available_tools)
    reviewers = [other_tool, claude]
    escalation = [implementer, other_tool, claude, user]
elif len(available_tools) == 1:
    implementer = available_tools[0]
    reviewers = [implementer, claude]  # mutual review
    escalation = [implementer, claude, user]
else:
    # pure metaswarm, no change
    implementer = claude
    reviewers = [claude_fresh_task]
    escalation = [claude, user]

Selection criteria for cheapest():

  1. Pick the tool with lower estimated cost per invocation (based on model pricing and average token usage from session logs)
  2. On tie, prefer the tool with higher historical success rate for this task type
  3. If no historical data, prefer Gemini (free tier) over Codex

Prompt File Format

The prompt file is the key interface between the orchestrator and external tools. It must be self-contained -- the external tool has no access to BEADS, knowledge base, or conversation history.

# Task: [task title]

## Acceptance Criteria
- [ ] criterion 1
- [ ] criterion 2
- [ ] criterion 3

## Context
[relevant file contents, token-budgeted]
[prioritized: changed files > test files > imports > surrounding context]

## Coding Standards
[extracted from project's CLAUDE.md / coding standards guide]
[language-specific rules, naming conventions, patterns]

## Test Expectations
[what tests should pass after implementation]
[coverage requirements from .coverage-thresholds.json]
[test runner command: e.g., npx vitest run]

## Previous Attempt (if retry)
[review feedback from last attempt -- what to fix]
[DO NOT include full prior output, only the actionable feedback summary]

## Prior Model's Attempt (if escalation)
[diff summary from previous model's branch -- what was tried, why it failed]
[DO NOT include full branch, only the relevant diff summary]

Token budgeting rules (handled by package_context() in _common.sh):

  • Estimate tokens per file using chars/4 heuristic
  • Prioritize context: changed files > test files > imports > surrounding context
  • Truncate to the model's context budget (configurable per adapter)
  • On retry: include review feedback summary, not full prior output
  • On escalation: include prior branch diff summary, not full branch

Error Handling

When an adapter returns exit_code != 0, the error_type field determines the orchestrator's response:

Error TypeMeaningOrchestrator Action
tool_not_installedBinary not foundSkip adapter, try next in escalation chain
auth_expiredAPI key invalid or expiredEscalate to user with setup instructions
auth_missingNo API key configuredEscalate to user with setup instructions
network_errorCannot reach APIRetry with exponential backoff, then skip adapter
rate_limitedAPI rate limit hitWait and retry (respect Retry-After if provided)
timeoutTool exceeded time limitRetry once with increased timeout, then skip adapter
context_too_largeInput exceeds context windowReduce context via package_context(), retry
cost_limit_exceededWould exceed budgetSkip adapter, alert user about budget status
tool_crashUnexpected exitRetry once, then skip adapter
output_parse_errorMalformed JSON outputLog raw output for debugging, treat as failure

General rules:

  • "Skip adapter" means move to the next tool in the escalation chain, not abort the task
  • All errors are logged to ~/.claude/sessions/ for self-reflection
  • Auth errors always escalate to the user -- the orchestrator cannot fix credentials
  • Network and rate-limit errors get transient-failure treatment (backoff + retry)

Budget Enforcement

Two circuit breakers prevent runaway costs:

Per-Task Budget (per_task_usd)

Before each adapter invocation, the orchestrator checks cumulative cost for the current task:

if task_cost_so_far + estimated_cost > per_task_usd:
    error_type = "cost_limit_exceeded"
    skip adapter, try next in escalation chain (or Claude)

Default: $2.00 per task.

Per-Session Budget (per_session_usd)

Before each adapter invocation, the orchestrator checks cumulative cost across all tasks in the session:

if session_cost_so_far + estimated_cost > per_session_usd:
    error_type = "cost_limit_exceeded"
    alert user: "Session budget exhausted. External tools disabled for remaining tasks."
    fall back to Claude for all remaining work

Default: $20.00 per session.

Cost Tracking

Cost is extracted post-execution from the adapter's JSON output (cost.input_tokens, cost.output_tokens) and converted to USD using known model pricing. Cost estimation is approximate (~15-30% variance due to different tokenizers per model). There is no pre-execution cost prediction in v1 -- cost is measured after execution, not capped before.


Anti-Patterns

#Anti-PatternWhy It's WrongWhat to Do Instead
1Trusting external tool self-reports -- tool says "all tests pass" and orchestrator believes itExternal tools can hallucinate, skip steps, or misinterpret results; same reasoning as the no-self-certification rule for subagentsOrchestrator runs Phase 2 (VALIDATE) independently; adapter output contains facts only, never verdicts
2Skipping cross-model review -- "the external tool's code looks fine, committing directly"Single-model blind spots are the whole reason this skill exists; bypassing review defeats the purposeAlways run Phase 3 with a different model as reviewer; cross-model review is mandatory
3Running without timeout -- invoking an adapter without safe_invoke() timeout wrapperExternal CLIs can hang on rate limits, network issues, or infinite loops; an unmonitored invocation blocks the entire pipelineAlways use safe_invoke() with the configured timeout_seconds; handle timeout as a retryable error
4Passing the full environment -- running the external tool with the orchestrator's full env varsLeaks API keys, session tokens, and internal state to an external process that only needs its own credentialsUse env -i to pass only HOME, PATH, and the tool's own API key; see Minimal Environment in the design doc
5Working in the main repo -- running external tools directly in the project working directory instead of a worktreeConcurrent invocations corrupt each other's state; failed attempts leave dirty files; no clean rollback pathAlways create an isolated git worktree per invocation; merge only after all phases pass

Logging

All adapter invocations produce structured session log entries in ~/.claude/sessions/:

Session log entry:
  - timestamp, tool, command, model, attempt
  - prompt content hash (what we asked)
  - output JSON (facts: exit code, files changed, cost)
  - CI gate results (from orchestrator's Phase 2)
  - review output (from cross-model Phase 3)
  - outcome: success | retry | escalated | user_alert
  - cost (tokens used, estimated USD)

These logs feed the existing /self-reflect pipeline. Over time, the knowledge base accumulates routing intelligence:

  • Patterns: "Codex excels at single-file TypeScript implementations"
  • Gotchas: "Gemini tends to skip error handling in async functions"
  • Routing decisions: "Route database migration tasks directly to Claude (external tools fail 80%)"

Future routing decisions improve automatically as the knowledge base grows from session log analysis.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.