| name | fakoli-claw-router |
| description | Choose how to handle a new coding request — native for tiny edits vs a fakoli-claw flow for multi-file, risky, design, or explicit crew/Fakoli work. |
fakoli-claw-router
Pick the lightest path that still preserves the four invariants. This skill decides between
staying native and invoking a flow:* skill — it does not re-implement any workflow. Once a route
is chosen, that flow skill is canonical: defer to it.
Full policy and rationale: docs/ROUTING.md.
Who routes
Routing is the job of the entry / coordinating agent — usually main or fakoli-orchestrator —
when it first picks up a request. If you are a specialist already executing a scoped packet (you
were handed one task with scope, acceptance criteria, and a verify command), do not re-route:
finish the packet and report evidence. If a request handed straight to a specialist genuinely needs a
flow, hand it back to main / fakoli-orchestrator rather than running a flow yourself.
Use this skill when
- A coding request could be multi-file, risky, or a refactor.
- It implements an architecture/design, or a design decision is still open.
- The user explicitly asks for the crew, a flow, Fakoli, or "the agents".
- Work should be delegated durably, or needs an evidence / "is it ready to ship?" check.
Skip this skill when
- You are a specialist mid-packet — complete the scoped task and report; don't re-route.
- The change is a tiny, low-risk edit (1–2 files) you can make and verify directly.
- It's pure Q&A, explanation, or summary with no implementation path.
- It's an emergency fix where orchestration latency is the bigger risk.
The four invariants
- Intent over recipe — pass goals, acceptance criteria, scope, and verify commands, not a
line-by-line script.
- Specialist over generalist — focused roles, one owner per file per wave.
- Evidence over claim — cite command output, artifacts, and gate results.
- Durability over chat — keep plans, run state, and scorecards outside the transcript.
Routing table
| Request shape | Route | Why |
|---|
| Q&A, explanation, summary; no implementation path | native | No crew value. |
| Tiny low-risk edit, ~1–2 files | native | Fastest path; direct verification is enough. |
| Small change under 3 files that wants one specialist + a review pass | flow:quick | Fast path plus a critic gate. |
| New feature, architecture change, unclear behavior, or unresolved human decisions | flow:brainstorm | Approve a spec before code. |
| Approved spec needing task decomposition | flow:plan | Intent-driven tasks: owners, scope, deps, verify commands. |
| Approved plan; multi-file, dependency-ordered, or risky | flow:execute | Waves, critic gates, sentinel evidence. |
| Existing work needs a readiness answer | flow:verify | Fresh evidence scorecard. |
| Verified branch needs merge / PR / keep / discard | flow:finish | Re-runs tests; waits for an explicit shipping choice. Never auto-merges. |
The flow skills are the canonical process — route to one, then let it run. Do not reimplement a flow
in this skill or in an ad-hoc prompt.
Direct specialist exception
Spawn a single specialist directly only when the work is narrow, bounded, and a full flow would add
noise. The packet still needs intent, acceptance criteria, exact scope, a verify command, and a
fresh session key.
fakoli-welder — integration, wiring, bug fixes, adapting existing code.fakoli-smith — OpenClaw plugins, commands, manifests, MCP/tool structure.fakoli-scout — codebase research, library/API verification; no code writes.fakoli-herald — docs, READMEs, changelogs, release notes, prose cleanup.fakoli-keeper — CI, infra, config, runtime, environment, scripts.fakoli-guido — architecture, interfaces, type design, naming, design review.fakoli-critic — review gate only.fakoli-sentinel — final evidence/acceptance gate only.
Do not route to fakoli-claw for
- Sensitive external actions: email, public posts, account changes, payments, or messages as the user.
- Emergency fixes where orchestration latency is the main risk.
- Tiny changes where direct editing and direct verification are cleaner.
- Execution that still depends on unresolved human decisions — use
flow:brainstorm first.
- High-volume work when the local tier is unhealthy and cloud fallback would materially change cost,
privacy, or risk. Ask before routing it to cloud or general agents.
If the crew or local tier is unavailable, fall back to native for small/medium work and say the crew
route was skipped. Still preserve the invariants: scoped ownership, explicit verification, evidence
reporting, and durable notes when useful.
Operational checks before a crew run
- Inspect repository context and current git state.
- Confirm fakoli agents exist:
openclaw agents list 2>/dev/null | grep -c '^- fakoli-'.
- For large runs, health-check the stack when practical with the repo's
evals/health-smoke.sh.
- Avoid dispatching during a gateway restart or drain window.
- Use a fresh
--session-key for every orchestrator or specialist run. Reusing the default
local-agent session bloats the local model's transcript and triggers compaction failures.
Reporting
When native handles the work, report files changed and the verify command. When a fakoli route
handles it, also report: the route used; verification evidence (command, exit status, or artifact);
critic/sentinel results when those gates ran; the durable plan/run/status path when relevant; and any
skipped verification or fallback. The goal is better routing and proof, not ceremony.
