Agent Coordination
ReviewAudited by ClawScan on May 18, 2026.
Overview
Review recommended: this is mostly a coherent agent-coordination skill, but it can persistently delegate requests to coding agents and includes a hard-coded local-folder “full autonomy” exception.
Install this only if you want the agent to act as a VibeKanban coordinator that can create tasks and dispatch coding agents. Before use, remove or override the hard-coded `/Users/clementwalter/Documents/rookie-marketplace` full-autonomy exception, require confirmation before starting workspace sessions, and make sure your GitHub CLI and VibeKanban permissions are limited to repositories you are comfortable delegating.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If that path exists or is relevant, the agent may act directly instead of merely coordinating, potentially changing files without the normal delegation boundary.
The skill presents a coordinator-only boundary, then adds a hard-coded absolute-path exception granting full autonomy. That exception is user-specific and materially changes the trust boundary.
### What You Do NOT Do - Investigate codebases (delegate it) - Implement features or fixes (delegate it) - Write or Edit code files **Exception**: Full autonomy in `/Users/clementwalter/Documents/rookie-marketplace`.
Remove the hard-coded path exception, or replace it with an explicit user-selected project scope and a confirmation step before any direct code changes.
The skill may create tasks and start coding agents on repositories, which can consume resources and lead to code changes or PR activity by delegated agents.
The workflow encourages dispatching executor agents as the default path, which can start autonomous coding sessions through VibeKanban without an explicit approval checkpoint described in the artifacts.
### 3. Always Try to Assign Don't just create tasks—dispatch agents to work on them.
Before enabling this workflow, require explicit confirmation of the project, repository, base branch, executor, and scope before starting each workspace session.
After activation, even direct requests may be converted into delegated tasks until the user explicitly exits CoS mode.
The skill intentionally changes how the agent interprets later user requests for the rest of the conversation. This is disclosed and aligned with Chief-of-Staff coordination, but it is a persistent instruction-scope change.
**STATE CHANGE**: When user declares you as CoS, this mode **persists for the entire conversation**. ... ALL subsequent requests become task delegations ... Never revert to execution mode unless explicitly told
Make the active mode visible in responses and use an explicit phrase such as “exit CoS mode” when you want normal execution behavior restored.
The script can access CI status and failed-job logs for repositories available to the local `gh` login.
The CI monitor runs GitHub CLI commands in the user's environment. For private repositories, those commands may use the user's existing GitHub CLI authentication and repository permissions.
run_gh(["pr", "checks", str(pr_number), "--json", "name,state,link,workflow"] + repo_arg) ... run_gh(["run", "view", run_id, "--log-failed"] + (["-R", repo] if repo else []))
Use it only with GitHub accounts and repositories you intend to expose to the agent, and review CI log output before sharing it further.
Running the helper script executes local GitHub CLI commands and may make GitHub API requests through that CLI.
The included helper script executes the local `gh` binary. This is expected for PR CI monitoring, uses an argument list rather than shell execution, and has a timeout.
result = subprocess.run(
["gh"] + args,
capture_output=True,
text=True,
timeout=30,
)Only run the helper when CI monitoring is intended, and ensure `gh` and `uv` are installed from trusted sources.
