Agent Skills › coleam00/Archon › archon-cli

archon-cli

GitHub

管理 Archon CLI 的 AI 工作流，包括运行、监控、审批及配置。指导 Agent 通过 CLI 驱动多步骤任务，涵盖工作流编排、状态管理及提示词优化，而非直接执行编码。

.claude/skills/archon-cli/SKILL.md coleam00/Archon

Trigger Scenarios

使用 archon 运行或管理工作流配置或设置 Archon 创建或改进工作流提示词查询或控制正在进行的运行

Install

npx skills add coleam00/Archon --skill archon-cli -g -y

More Options

Non-standard path

npx skills add https://github.com/coleam00/Archon/tree/dev/.claude/skills/archon-cli -g -y

Use without installing

npx skills use coleam00/Archon@archon-cli

指定 Agent (Claude Code)

npx skills add coleam00/Archon --skill archon-cli -a claude-code -g -y

安装 repo 全部 skill

npx skills add coleam00/Archon --all -g -y

预览 repo 内 skill

npx skills add coleam00/Archon --list

SKILL.md

Frontmatter

{
    "name": "archon-cli",
    "description": "Drive Archon through its CLI: run AI workflows on a repo, manage those runs\n(inspect, approve, reject, cancel, resume), set up Archon or change its config,\nauthor new workflows, and improve workflow prompts. Use when the user says \"use archon\", \"run archon\",\n\"archon workflow\", \"fix issue #N with archon\", \"have archon review this PR\",\n\"what's running \/ check run <id>\", \"approve\/reject\/cancel\/resume that run\",\n\"set up archon\", \"configure archon\", \"change my archon config\",\n\"create a workflow\", \"author a workflow\", or asks how to write a better Archon prompt.\nNOT for: doing the coding work yourself — Archon delegates it to isolated runs.\n",
    "argument-hint": "[workflow | run-id | intent]"
}

Archon CLI

Archon runs multi-step AI workflows through the archon CLI. Git projects use isolated worktrees by default; registered folder projects run in place. This skill has five capabilities; route by intent:

User wants to...	Read
Run workflows on real work	`running-workflows/running-workflows.md`
Manage existing runs (inspect/approve/reject/cancel/resume)	`manage-run/manage-runs.md`
Set up Archon or change config	`setup-and-config/setup-and-config.md`
Author a new workflow	`authoring-workflows/authoring-workflows.md` (+ its `node-reference.md`)
Improve prompts for workflow nodes or run messages	`prompting-mistakes/prompting-mistakes.md`

Routing rules:

Intent is clear from the request ("build me a workflow for X", "run archon-ship on issue #42") → route directly. Do not ask.
Genuinely ambiguous → ask the user which capability they want, listing these five.
First contact with an unconfigured machine → setup-and-config/setup-and-config.md before anything else.

Quick spine: running a workflow

Most requests land here. The short version; details in the running reference:

Discover what exists with the compact catalog: archon workflow list --json. Use its previews to identify plausible candidates, and treat descriptionTruncated: true as an explicit signal that a description is incomplete — never assume names from memory.
Fetch each plausible candidate's untouched description with archon workflow list <name> --full. Choose from the full descriptions, not a truncated preview.
Check the input before spending anything. The message (or the issue, or the document the run reads) is the contract the whole run is measured against. Hold it against the six in running-workflows.md — problem, why it matters, why now, outcome, invariants, acceptance. If any is missing, say which, propose a corrected input, and get the user's agreement before launching. Do not silently improve it, and do not launch anyway.

Invoke detached by default (workflows are long-running):

archon workflow run <workflow> --branch <branch-name> "<the work, as a clear message>" --detach

Find the run id (archon workflow runs --json), then arm archon workflow wait <run-id> --json as a background task of your harness — it blocks until the run ends or needs a human decision, waking you at exactly the right moment. archon workflow get <run-id> --json is for on-demand state, not a polling loop.
When a run pauses at a gate, resolve it deliberately: see manage-run/manage-runs.md.

Four hard rules:

Never launch against a thin brief. A weak input does not produce a weak result — it produces a confident, well-formed answer to the wrong question, at full price.
A fresh launch of an interactive-class workflow refuses --detach. Run that launch in the foreground as a background task of your harness. Once the run pauses, resume/approve/reject/respond --detach are supported continuation actions.
Prefer --detach if the workflow is not interactive.
One workflow per shell; multiple tasks = separate invocations, separate branches.

Gotchas

The current directory selects the project for workflow discovery, launches, and project listings. workflow status and workflow runs default to that project; use --all only when install-wide visibility is intended. Their JSON output sets scopeFallback: true when an unregistered project produces an install-wide result. workflow status fails if the registry lookup itself fails; it does not disguise the error as an unregistered-project fallback. Commands given a full run ID remain globally addressable. For a git project, run from the repo root. Register a non-git project with workflow run --folder.
A completed run does not mean the work succeeded. Use workflow get <run-id> --json for the normalized outcome and leave_behind.artifactFiles; use a separate --verbose --json call for node summaries.
Prefer --json whenever you will parse output.

Resources

running-workflows/running-workflows.md — discovery, invocation, isolation, monitoring
manage-run/manage-runs.md — every run-control verb, gate semantics, JSON shapes
manage-run/troubleshooting.md — log locations, JSONL event types, jq recipes
setup-and-config/setup-and-config.md — install, doctor, config.yaml scopes, provider auth
authoring-workflows/authoring-workflows.md — designing a workflow: primitives, gates, prompts
prompting-mistakes/prompting-mistakes.md — common prompt mistakes, for authored nodes and for the messages you pass when invoking workflows