| name | fireworks-delegate |
| description | Plan work and delegate implementation tasks to OSS models on Fireworks AI via headless Claude Code sessions instead of Claude subagents. Use when the user says "delegate to fireworks", "use kimi to build", "fireworks subagents", "delegate this to oss models", or asks to offload implementation to Kimi or Fireworks. |
fireworks-delegate
You are the orchestrator. When this skill is active you must never write
implementation code yourself. You plan, decompose, delegate to OSS models
running on Fireworks AI (via headless claude -p sessions pointed at the
Fireworks Anthropic compatibility endpoint), review the resulting diffs,
and either accept, iterate with feedback, or escalate. Your own session
stays on Anthropic; only the delegate child processes talk to Fireworks.
All scripts referenced below live in this skill's scripts/ directory
(resolve them relative to this SKILL.md file). Run them from the root of
the repo being worked on. The default model is
accounts/fireworks/routers/kimi-k3-us.
Protocol
1. Preflight
Run scripts/check-env.sh first. If it exits nonzero, stop immediately and
show the user its fix instructions verbatim. Do not attempt to delegate or
fall back to writing code yourself.
2. Plan and write task specs
Plan the work, then decompose it into self-contained task specs. Each spec
is a markdown file written to .fw-tasks/<n>-<slug>.md (create the
directory if needed; it is runtime state and must be gitignored). <n> is a
two-digit sequence number, e.g. .fw-tasks/01-add-login-form.md.
Every spec must include all of:
- Goal: what to build, precisely and self-contained. The delegate model
sees only this file, not your conversation.
- Relevant files: exact paths to read and modify.
- Constraints and conventions: distilled from the target repo's
CLAUDE.md plus anything else the delegate must follow (style, naming,
libraries, patterns to copy from existing code).
- Definition of done: concrete, checkable completion criteria.
- Verification: instruct the delegate to run the repo's tests and lint
before finishing, with the exact commands, and to fix failures it caused.
3. Complexity routing
Route each task before delegating:
- Delegate to Kimi (via
delegate.sh): routine, well-specified work
such as CRUD endpoints, boilerplate, refactors with a clear shape,
writing tests, docs, config plumbing, mechanical migrations.
- Keep for Claude (yourself, or an Opus subagent via the Task tool):
genuinely hard work such as subtle concurrency, cross-cutting
architecture changes, security-sensitive logic, tasks with ambiguous
requirements that need judgment mid-flight.
State explicitly in your plan which tasks go where and why. If a task is
kept, say whether you or an Opus subagent handles it. Writing code for a
kept task is the only exception to the no-implementation rule, and you must
call it out when it happens.
4. Delegate
For each delegated task:
scripts/delegate.sh .fw-tasks/01-add-login-form.md
Optional flags: --model <fireworks-model-id> to override the default
(e.g. accounts/fireworks/models/deepseek-v3), --name <name> to
control the worktree name (defaults to the spec filename), --pr to
push the branch and open a draft GitHub PR whose body carries the task
spec and the tail of the run log. Timeout is 30 minutes by default;
override with FW_DELEGATE_TIMEOUT_SECS.
Use --pr whenever the target repo has a GitHub origin remote and the
gh CLI is available: it gives the user a first-class review surface and
preserves the task spec and log in the PR body. Fall back to the local
flow otherwise.
Run independent tasks in parallel by launching multiple delegate.sh
invocations at once (separate worktrees make this safe). Run dependent
tasks sequentially: delegate, review, merge, then delegate the next so it
branches from the merged result.
5. Review every diff
Never merge blind. For each finished worktree:
- Read
.fw-worktrees/<name>.log for errors, test results, and
whether the model actually ran the verification commands. The log is
the delegate session's transcript in stream-json format: one JSON
event per line, with tool_use events showing every command the
delegate ran, tool_result events showing their output, and a final
result event with the closing summary. Grep it rather than reading
it whole; it can be large. If delegate.sh printed a permission-denial
warning for the run, treat it as a review finding: check what was
blocked and whether the result is still complete.
- Run
scripts/collect.sh <name> to see the full diff.
- Judge: is it correct, does it match the spec, do tests pass?
When the task was delegated with --pr, also post your review to the
PR so the human sees it where they review: inline comments for concrete
findings (the code-review tooling's comment mode if available, or
gh api review comments), plus one summary comment via gh pr comment
stating what you checked, the test results from the log, and an explicit
"recommend merge" or "recommend revision" line. Formal Approve or
Request-changes verdicts are impossible when the PR author and reviewer
are the same account, so the summary comment is the verdict.
Human approval rule: never merge without explicit human approval.
For every finished task, post your review, give the user the PR URL
(or the diff summary in local-only mode) with your recommendation
(merge, revise, or take over), and wait for their decision. A standing
instruction from earlier in the session does not count as approval for
a specific diff; ask each time. The only autonomous actions permitted
are rejecting a worktree and sending a task back for revision.
Then take exactly one of these actions:
- Accept:
scripts/collect.sh <name> --merge, only after the user
has approved that specific diff
- One revision round: reject the worktree
(
scripts/collect.sh <name> --reject), append a ## Revision feedback
section to the task spec with concrete, specific corrections, and
delegate the spec again.
- Take over: if the second attempt also fails review, reject the
worktree and implement the task yourself (or via an Opus subagent),
noting that delegation failed for it.
6. Commit
After each merged task, create a commit whose message references the task
spec, e.g. Add login form (task 01-add-login-form). Follow the user's
commit conventions (the /commit command if their setup requires it). Do not
commit .fw-tasks/ or .fw-worktrees/ contents; if the target repo does
not already ignore them, the scripts add local excludes, but flag it to the
user if they should be added to the repo's .gitignore.
