bounded-work-item
Execute one scoped implementation or investigation item and return evidence without changing workflow authority.
git clone --depth 1 https://github.com/SeemSeam/claude_codex_bridge /tmp/bounded-work-item && cp -r /tmp/bounded-work-item/docs/plantree/plans/agentic-loop-workflow/drafts/agentroles.coder/skills/bounded-work-item ~/.claude/skills/bounded-work-itemSKILL.md
# Bounded Work Item Use this skill when the controller supplies one canonical node work packet with declared refs, scope, non-goals, dependency evidence, acceptance refs, allowed paths, and verification refs. The only Coder terminal status enum is `done|blocked|needs_rework`. ## Workflow 1. Read only the canonical node work packet and its declared refs. 2. Inspect relevant files before editing. Detect repository metadata once; if the assigned workspace is not a Git checkout, do not keep trying Git commands. Use the assigned paths, direct file inspection, focused tests, and runner-provided promotion evidence instead. 3. Make the smallest change that satisfies the packet inside its allowed paths. Do not expand scope or inspect sibling packets. 4. Run focused verification when possible. 5. After verification, use only the assigned-review chain skill to submit the evidence to the assigned Reviewer, then stop for continuation. 6. Apply bounded requested rework when returned. After Reviewer pass, perform no more file/tool mutation and immediately return changed paths, verification evidence, blockers, and `done`. ## Boundaries - Do not lower acceptance criteria. - Do not silently substitute fallback behavior. - Do not claim whole-round success. - Do not directly edit authoritative CCB state or runtime files. - Do not run CCB commands or workflow wrappers except the exact assigned Reviewer `ask --chain --artifact-reply` operation. - Do not submit other downstream asks, create authority commits, integrate sibling work, promote project-root state, or release agents. - Provider and model selection remain project configuration concerns. This RolePack is provider-neutral and must not assume a specific provider.
Maintain this CCB project's GitHub-facing release and npm publication surface. Use when preparing, publishing, auditing, or fixing CCB releases; updating README.md, README/zh.md, localized README files, CHANGELOG.md, VERSION, package.json, GitHub release notes/assets, repository description/topics, npm registry state, or GitHub Actions release/test status.
Private built-in CCB configuration skill for agentroles.ccb_self. Design, edit, validate, and prepare reloads for .ccb/ccb.config, role bindings, providers, windows, workspaces, tool windows, sidebar, and provider startup inputs. Use only inside ccb_self; non-self agents should delegate CCB config changes to ccb_self.
Diagnose and repair CCB ask/job/message/reply/artifact/callback lineage. Use for missing replies, incomplete artifacts, pending callbacks, retry/resubmit/ack decisions, reply delivery problems, or work-chain resume advice.
Diagnose CCB runtime, mounted daemon graph, tmux namespace and panes, provider context, queue/inbox/trace, replies/artifacts, config drift, and storage boundaries. Use when the user asks what is broken, which agent is stuck, whether CCB is mounted, why a reply did not arrive, or what to check first.
Recover CCB agents, panes, mounts, provider contexts, API/provider failures, config reload aftermath, clear operations, and guarded single-agent restarts. Use when the user asks to fix, recover, restart if safe, clear context, reload, remount, or keep work going after provider/API failure.
Send a request to a CCB agent with `ask`.
Clear CCB managed agent conversation context with `ccb clear`. Use when the user writes `$ccb-clear`, `$ccb_clear`, or asks to clear/reset one or more CCB agent contexts without restarting or deleting project state.