drive-clique
Skill3 starsChanged 28 days agoMITView on GitHub
Drive CLIque over its HTTP API to run and coordinate coding agents on a box — start sessions, send prompts, read output, and wait for one to finish or come back asking. Use when a task means running work across several repos or agents at once and collecting the results, rather than doing it all in one session.
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 0 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 26
Use --read-only for a token that may observe but not start or stop anything.
- Very specific: line 30
Every session in GET /api/state carries a state:
- Very specific: line 47
Add {worktree: true, branch: "<name>"} to run it in an isolated git worktree of the repo at cwd — the way to put several agents on one repo …
- Very specific: line 80
Wait, don't spin: Use /wait, not a loop over /api/state.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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.
Files
Driving CLIque
CLIque runs coding-agent sessions (Claude, Codex, Grok, a shell, …) in tmux and exposes every action as an HTTP call. That is the point: anything the panel can do, a script or an agent can do. This skill is the orchestration surface.
Connect
Base URL is the panel's own — http://127.0.0.1:3200 on the same box, or the
tailscale URL from off it. Authenticate with a bearer token, not a cookie:
CLIQUE_TOKEN=$(python3 -m clique token create my-agent | grep -oE 'mxp_[A-Za-z0-9_-]+') # shown once
curl -H "Authorization: Bearer $CLIQUE_TOKEN" http://127.0.0.1:3200/api/stateUse --read-only for a token that may observe but not start or stop anything.
The one word that matters: state
Every session in GET /api/state carries a state:
| state | meaning |
working | producing output right now |
waiting | stopped and asking a person something (needs input) |
error | stopped on something that looks like an error |
idle | up, quiet, nothing pending — a task that finished cleanly |
stopped | no process (killed or never started) |
Orchestration is: start work, then wait for idle (done) or waiting (it needs
you) — never a tight poll of the whole panel.
Endpoints
GET /api/state— every session, each withid,name,cli,cwd,state,rss.POST /api/sessions— start one. Body:{cli, cwd, name?, folder?, mode?}. Add{worktree: true, branch: "<name>"}to run it in an isolated git worktree of the repo atcwd— the way to put several agents on one repo without them clobbering each other. Returns{id, worktree}.POST /api/sessions/<id>/send—{text, enter: true}submits a prompt.GET /api/sessions/<id>/peek?lines=N— the last N lines of the pane.GET /api/sessions/<id>/transcript— the full conversation as turns (Claude).GET /api/sessions/<id>/wait?for=idle,waiting&timeout=60— blocks until the session reaches one of theforstates or the timeout (max 300s). Returns{state, matched, waited}. This is the primitive to build on.POST /api/sessions/<id>/kill— stop it (keeps the record, resumable).DELETE /api/sessions/<id>— remove it. A worktree CLIque made is removed too, but only when it has no uncommitted changes.
Recipe: one task across many repos
auth=(-H "Authorization: Bearer $CLIQUE_TOKEN"); base=http://127.0.0.1:3200
for repo in /root/platform/relay /root/platform/sentinel /root/platform/clique; do
id=$(curl -s "${auth[@]}" $base/api/sessions -d \
"{\"cli\":\"claude\",\"cwd\":\"$repo\",\"worktree\":true,\"branch\":\"audit\",\"name\":\"audit $(basename $repo)\"}" \
| python3 -c 'import sys,json;print(json.load(sys.stdin)["id"])')
curl -s "${auth[@]}" $base/api/sessions/$id/send -d \
'{"text":"Audit this repo for security issues and write findings to AUDIT.md.","enter":true}' >/dev/null
echo "$id" # collect the ids
done
# then, for each id: wait for it to finish or come back asking
curl -s "${auth[@]}" "$base/api/sessions/$id/wait?for=idle,waiting,error&timeout=300"
# idle -> done; waiting -> it needs an answer; peek to see what it said:
curl -s "${auth[@]}" "$base/api/sessions/$id/peek?lines=40"Rules
- Wait, don't spin. Use
/wait, not a loop over/api/state. It holds the connection until the state changes, capped at 300s — call again for longer. - Reads are bounded.
peekandtranscriptreturn a tail, never a whole 30 MB transcript. Ask for the lines you need. - Worktrees for parallel same-repo work. Two agents in one working tree fight over files; one worktree each and they do not. Delete the session to clean up.
- A shell is not resumable. Killing a
shellsession loses its state; killing a Claude/Codex one does not — it starts again where it was.
In this repository11 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- animateSkill
- animation-vocabularySkill
- apple-designSkill
- clique-motionSkill
- clique-release-checkSkill
- clique-three-surfacesSkill
- emil-design-engSkill
- find-animation-opportunitiesSkill
- improve-animationsSkill
- review-animationsSkill
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
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.

