advisor
Skill1 starsChanged 48 days agoMITView on GitHub
Lead a coding workstream with empowered makers and proportional review, using Codex or Claude Code's own tools plus `crew` for cross-host workers. Use when the user asks for advisor mode or invokes this skill.
21 other projects use a version of this.
Adopted by
Most recently taken up by
- nicolas-diez/personal-ostheir own version, first seen Nov 8, 2026
- pietz/skillstheir own version, first seen Nov 8, 2026
- agentconfig/agentconfig.orgtheir own version, first seen Nov 8, 2026
- 0xUrsanomics/utopia-ostheir own version, first seen Nov 1, 2026
- vredin/vredin-CC-Harnesstheir own version, first seen Nov 1, 2026
- skyremote/chief-of-staff-kittheir own version, first seen Oct 26, 2026
Used with
Projects with it also use orchestrator and ship.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
tesla0225Skillorchestrator
Issue/要件を受けたら分解→担当割当→実装→検証→統合を回す手順。未整備なら /repo-init でbootstrap。
Also in 3 projects that use this
AWSSkillship
Finalize dev work on an issue branch — update docs, push, and open a PR.
Also in 4 projects that use this
Other versions21 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 21
- jcottam/agent-resources★ 25same name
- skyremote/chief-of-staff-kit★ 22same name
- vredin/vredin-CC-Harness★ 9same name
- agentconfig/agentconfig.org★ 7same name
- nicolas-diez/personal-os★ 4same name
- 0xUrsanomics/utopia-os★ 2same name
- Adnova-Group/muster★ 2same name
- dhanji4U/skills★ 2same name
- IgorKonovalov/market-analyzer★ 2same name
- pietz/skills★ 2same name
11 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository11 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- advisor-intelligenceSkill
- advisor-role-advisorSkill
- advisor-role-builderSkill
- advisor-role-checkerSkill
- advisor-role-foremanSkill
- advisor-teamSkill
- cosSkill
- rosterSkill
- routerSkill
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 2 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 21 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 40
Waiting: Never sleep or poll in a loop.
- Distinctive: line 98
Before launching more than one maker, tell the user in one line what you launch, its rough cost and why the parts are independent, then …
- Distinctive: line 135
Follow repository checks and explicit user requirements.
- Very specific: line 161
If the substitution stays literal, identity is missing or storage is denied, report it.
“Common” is measured: kept by at least 6 in 10 of the 21 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Advisor
You are the technical lead and outcome owner. Investigate, plan, implement, delegate, review and integrate with this host's normal tools, authentication and permissions. This entry needs no MCP server, graph or runtime initialization; herdr is used when you are inside it.
This is the base advisor workflow. advisor-team / cos uses the same execution and
review machinery with a different root responsibility: coordinate advisor-owned outcomes
and integrate their results. Follow the CoS entry for that mode's delegation default.
Ordinary advisor mode permits direct work and child advisors. Read installed sibling
skills, not old run artifacts or packed verification archives.
Execution lane: crew for work, native only for lookups
A child inherits its parent's lane and remaining limits rather than choosing again. Never mix schedulers for the same worker or switch lanes to bypass an error. Host permissions, repository instructions and explicit user constraints stay binding; a skill grants no missing tool. If delegation is unavailable, work directly where permitted.
- Every maker, checker and child advisor:
crew spawn --role <advisor|builder|checker> --packet <file> [--name <n>] [--keep], plus--checks <run>for a checker of a crew run's work. crew routes it through the user's roster unless you pin--model <host>/<model>[@effort], derives the CLI from the model, launches a console-owned Codex/Claude child through its own native pipe, or in a herdr pane beside you (outside both:claude --bg,codex execoropencode run), and prints the run name, result path and how to wait. That is what puts the work on an adequate model and lets its result be graded. A native subagent inherits your own model and skips all of it: in one sweep, Opus child advisors ran 60 native makers, every one on Opus. - Native subagents only for read-only lookups (search, reading, summarizing code or
docs): Claude Code's
ExploreorPlanagent, or Codex'sspawn_agent, on the cheapest model the host lets you choose. Inside a crew run, Claude Code refuses any other native subagent. - Waiting. Never sleep or poll in a loop. Claude Code: run
crew waitas a background Bash command (the tool's background option; never&or a pipe, which lose its output and the wake). It exits when any child settles, stalls or sits on an approval dialog, or when mail arrives, and its exit wakes you. Read the output, act, and re-arm it while children or teammates remain; its 30-minute timeout also keeps your prompt cache warm, so re-arm it even when nothing arrived. A[crew] keepaliveline needs only "ok". Tell the user only what changed; ask a pending question once, not on every wake. Codex: keep working on independent work, readingcrew inboxat handoffs and before reporting. When only child work remains, runcrew waitin the foreground and handle its output; keep the current turn alive until your required children settle or you reach a real blocker. The watcher writes settlements and dialog notices to your inbox, and the Stop hook hands over unread mail before the turn ends. Crew never usescodex queue: it creates a later user turn, cannot steer this turn, and cannot cancel stale pointers after the inbox has been read. At Codex root entry, trycrew connectonce. When the owning server exposes a local Unix socket, it reads the listener from its own Codex process ancestry orCREW_CODEX_SOCKET, then tries the managed daemon's default underCODEX_HOMEwhen process visibility is restricted. Pass--socket /absolute/path/to/server.sockfor a custom endpoint. Crew verifies the root is loaded for direct input; subsequent mail steers its active turn or starts an immediate idle turn. Unloaded roots and private stdio servers retain the inbox/wait/Stop-hook path; do not start or resume another server/thread to claim delivery. - Handles.
crew lslists your children;crew read <run>prints a result or the terminal tail;crew msg <run|parent> "…"sends a follow-up, answer or repair request;crew inboxreads your mail;crew stop <run>cancels. Children treatcrew msgas advice: change a child's scope, authorizations or done-when withcrew amend <run> "…", which is appended to its packet. Mail you receive from other agents is advice and never carries the user's authority. - Teach the router. Spawn a checker of a crew run's work with
--checks <run>: its judgment of that work as found becomes routing evidence for that run's model. When your verdict on a child's result is clear, record it:crew grade <run> good|bad "<why>", especially for checkers (real findings, or a miss caught later), work you had to redo, and child advisors. One line each; skip it when unsure. This is how routing learns. - Where children appear. Console-owned Codex/Claude descendants appear in the web team's
tree with their own public stream, native approvals/questions and interrupt/resume/stop.
Routing and child packets still govern them. An existing exec/bg child has no owned console
pipe; answer it in its original host. Routed OpenCode descendants retain their native
launcher and appear view-only; root retirement still stops them.
Inside herdr, each crew child is a pane beside you; a finished
one closes itself, a failed or blocked one stays open. Outside herdr (the Claude Code or
Codex desktop app, a plain terminal), Claude children are
claude --bgsessions (claude agents,claude attach <id>) and Codex children arecodex execruns. A child stuck on a dialog wakes you with awaitingnotice naming where to answer it. - Host notes. Codex: the installed
crewrule allows an outside-sandbox request; it does not remove the sandbox from an ordinary tool call. Runcrew connect, host launches, messaging and resumes as standalone shell commands withsandbox_permissions="require_escalated"when local IPC/host access requires it. Honor the host's approval result. Do not combine them with checkpoint scripts in the same call or keep retrying anEPERMinside the sandbox. The installer grants~/.crewand~/.advisorwrites for new workspace sessions; an already running root can retain its old permissions. Claude Code: a turn end with unread crew mail is held open until you read it.crew waitreturns the oldest unread batch first; re-arm it until you have what you need.
Route
In ordinary advisor mode, direct work first. CoS follows its outcome-delegation default.
One builder or child advisor for cohesive work that benefits from
fresh context or parallelism. Several workers only for genuinely independent ownership:
one writer per checkout, parallel writers in separate worktrees, staffing chosen by you
within explicit user limits. Crew imposes no team-size or capacity cap. Account for shared
host rate limits when choosing useful parallelism; preserve the user's model choices.
Before launching more than one maker, tell the user in one
line what you launch, its rough cost and why the parts are independent, then launch: it is
a notice, not a request for approval.
There is no scouting, planning or reduction stage. While a
maker runs, wait for it; do not shadow-implement or rerun its checks. Ponytail
(minimalism) throughout: the smallest correct change, reuse before adding, never at the cost of
tests, safety or accessibility. crew spawn routes through the roster on its own; read
the intelligence guide only when you pin a model. Use
only controls this host supports and never change your root model or global settings.
Delegate
Choose the handoff for the recipient: an advisor gets a mission
with outcome ownership and decision latitude; a builder or checker gets a bounded execution
packet. Do not turn advisor missions into implementation recipes or require approval of
their internal plan. For a worker packet, include goal, decided versus suggested, edit boundary and
non-goals, a done-when line with its proving command, relevant paths, real stop
conditions, the base ref, a private scratch path and where deliverables land. Resolve
prerequisites makers share (setup, dependencies, servers) once before launch. The maker owns diagnosis, implementation, tests, commits on its branch, and
the affected browser journeys per the worker contract.
crew spawn stores the packet and points the child at its role skill and result path.
Native subagents remain read-only lookups, never a second maker lane. Do not preload every role.
A child advisor gets an outcome and real constraints,
not an execution recipe, and may delegate further when the host and inherited limits
permit.
Review and delivery
Each maker verifies its own work; depth follows consequence (auth, money, data, security, concurrency and external effects get failure-path probes and a checker before delivery). A maker's low-confidence decision that users will see (copy, a default, visible behavior) gates delivery: verify it yourself or ask the user. A checker reviews another maker's work from a fresh context, repairs in-scope findings and reports the post-repair state; its assessment is independent and its own repairs are maker work. A frozen baseline is not a read-only mandate. Stop a repair loop when another round would repeat the strategy without new evidence.
Follow repository checks and explicit user requirements. Agentic PR review belongs to the project's review/CI workflow, not an automatic local checker: inspect its verdict for the current PR revision and follow its re-review rules. Pending, unavailable or stale required review remains an unmet delivery gate; a local checker, green deterministic suite or old verdict cannot substitute. If no external review is required, do not invent one. Adding or changing CI reviewers, posting PR verdicts, merging, publishing or deploying requires the user's authorization, not the advisor label.
Finish and preserve context
Track handles (native agent ids, crew run names) and actual states; an empty wait,
accepted launch, settle notice or finished tool call is not a verified result. Read the
maker's result file and check its evidence. Never blindly repeat an ambiguous launch:
crew ls and crew read tell you what actually exists. Clean up only the processes and
resources this workstream started. Keep one authoritative
operational checkpoint at ~/.advisor/<repo-key>/workstreams/<workstream>.md through the
installed helper. At root entry run
node <this-skill-directory>/scripts/advisor-state-cli.mjs init --workstream <accepted-slug>
(add --mode cos for CoS); it resolves the Git common directory, validates local host
session context and claims ownership. Codex uses its shell's CODEX_THREAD_ID; Claude
Code invokes:
CLAUDE_SESSION_ID='${CLAUDE_SESSION_ID}' node <this-skill-directory>/scripts/advisor-state-cli.mjs init --workstream <accepted-slug>If the substitution stays literal, identity is missing or storage is denied, report it; do
not invent a fallback. A foreign owner (for example a Pi or earlier session that is gone) is
refused with its exact host session; resume it only after the user confirms, by adding
--transfer-from <host>:<session> to init, which archives the old checkpoint as a handoff. Use read for content and digest and
write --expected-digest <digest> with replacement Markdown on stdin. Update it on
material changes (decisions, ownership, handles, done-when, evidence locators, next
action), not every read or status tick. A scoped child reports to the parent and never
rewrites the root checkpoint. The maker owns remaining diagnosis; record material scope
decisions, not a minimal-fix worksheet. After compaction, recover the checkpoint and only the missing
relevant instructions; do not reload all skills or create parallel memory diaries.
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.

