Overview · AgentDock

Code Sentinel is a Claude Code plugin with a set of skills for reviewing, debugging and testing code, and a delivery pipeline that turns GitHub issues into merged pull requests with a fleet of parallel Claude sessions. AgentDock is the control plane for that fleet: it starts the plugin's orchestrator, watches what it does and records what it cost.

The plugin works on its own, without AgentDock. AgentDock does not work as a fleet manager without the plugin.

Install the plugin

The plugin repository is a Claude Code plugin marketplace. In Claude Code, run:

Claude Code

/plugin marketplace add AndreyBegma/claude-code-plugin
/plugin install code-sentinel@code-sentinel

Install it into the Claude profile your runner uses (the directory CLAUDE_CONFIG_DIR points at, or ~/.claude). The runner reads <CLAUDE_CONFIG_DIR>/plugins/installed_plugins.json and shows the plugin version on Admin → Runners.

The README on main may differ

At the time of writing, the README on the plugin's main branch still shows older clone-based install instructions. The commands above are the marketplace install, which the repository supports through .claude-plugin/marketplace.json. A README update with these commands is on a separate branch.

Without the plugin system, you can copy the repository's skills/ directory into a project's .claude/skills/ or into ~/.claude/skills/. Skills installed that way are invoked by their short names, such as /cs-spec.

Requirements

Claude Code, and gh signed in (gh auth login), inside a git repository.
For the orchestrator: git 2.31 or newer, tmux 3.2 or newer, python3 and claude on PATH.

Command names

Installed as a plugin, every skill is invoked as /code-sentinel:<name>, for example /code-sentinel:spec or /code-sentinel:orchestrator start. This is the form the skills use to call each other and the form AgentDock sends. Depending on your Claude Code version, the same skill may also be listed under its frontmatter name, such as /code-sentinel:cs-spec.

Skills

Delivery pipeline

Skill	What it does
`spec`	Interviews you in rounds, checks the result against the project's decisions, splits it into slots for parallel agents, and lands it as a GitHub issue (plus an optional spec file). See Specs and grilling
`issue`	Creates GitHub issues from findings or a description. `--auto` skips confirmation, `--ready` adds the ready label, `--depends-on` writes `Depends on #N` lines
`estimate`	Evidence-based estimate for an issue, a spec or the whole ready queue. Asks who executes it (the agent fleet, a team, or both compared); `--post` adds a comment and a `size:` label
`feature`	One feature or bug from request to pull request in your own session: study, plan, approval (or `--auto`), branch, implementation with checks, pull request
`orchestrator`	Runs the fleet unattended: reads the ready queue, dispatches one worker session per slot into its own git worktree, merges green pull requests, resumes dead workers, refills slots. See Orchestrator workflow
`worker`	What a dispatched session runs: one brief, one issue, one worktree, inside a file fence. It opens the pull request and stops before the merge

Review and analysis

Skill	What it does
`review`	Quick review of local staged and unstaged changes
`pr-review`	Reviews a pull request and posts comments on GitHub
`pr-merge`	Extracts rules from pull request comments into a `CLAUDE.md` pull request
`security`	OWASP Top 10, secrets, injection and auth scan
`arch`	Architecture consistency check, or a whole-project drift audit
`perf`	N+1 queries, re-renders, memory leaks, bundle size
`dead-code`	Unused exports, files and packages (high token usage; pass a path)
`debug`	Root cause of a bug from an error, a stack trace, a symptom or an issue
`conflict`	Resolves merge conflicts for a pull request or branch

Tests, UX and product

Skill	What it does
`test`	Writes the test (unit or integration) that would have caught a fix's bug
`unit-test`	Writes unit tests for a diff
`ux-review`	UX friction analysis with before and after proposals
`ux-scenario`	Generates UX test scenarios from a pull request, branch or description
`ux-test`	Runs UX scenarios in a browser, with screenshots and a report
`seo`	SEO findings from Google Search Console exports
`analytics`	Flow and funnel analysis from GA4 and Search Console data
`history`	Project retrospective from pull request history
`repo`	Product completeness audit per role, including hardcoded data
`init`	Scaffolds a Bun, Turborepo, NestJS, Prisma and Next.js monorepo (manual only)

The kill guard hook

The plugin also installs one PreToolUse hook on Bash, hooks/kill_guard.py, active in every session. It refuses pkill, killall, and kill with anything but literal numeric PIDs (kill $(pgrep …), kill %1, kill $PID), including inside ;, &&, pipes, $( ) and sh -c. kill 12345 is allowed. It exists because a pattern kill once stopped unrelated processes belonging to other projects on the same machine.

How AgentDock relates to the plugin

AgentDock drives and observes the plugin. It never reimplements the orchestrator's scheduling. All decisions about which issue runs in which slot, on which model, and when to merge stay inside the orchestrator skill.

What AgentDock does:

Starts and stops the orchestrator. Project → Fleet → Start… launches /code-sentinel:orchestrator start (or next) in a tmux session named agentdock-orch-<owner>-<repo>, with the runtime profile, model and permission mode you choose. Stop ends that session; workers keep running.
Reads what the plugin leaves on disk. Round boards and briefs under <git-common-dir>/cs-orchestrator/, each worker's .orchestrator-reply.md, cs-* tmux panes and .wt-<repo>-<slot> worktrees, plus pull requests and checks through gh.
Sends the same inputs a person would. Stopping a slot kills its tmux session. Messaging a worker writes .orchestrator-msg.md in its worktree and pokes the pane, exactly as the orchestrator does.
Reads .code-analyzer-config.json when a project is connected, and never writes it. See Config reference.
Uses GitHub issues as the queue. An issue with the ready label (cs:ready by default) is work. AgentDock has no task tracker of its own.

AgentDock refuses to run orchestrator and worker as ordinary skill runs. They only make sense in the fleet.

Plugin changes AgentDock benefits from

AgentDock lists the plugin changes it uses in its own docs/plugin/code-sentinel-changes.md. It keeps working without every one of them. Status at the time of writing:

Change	What it adds	Plugin status
Structured events (plugin #5)	`events.jsonl` and `state.json` written by `emit.py`, including worker checkpoints	merged on `develop`, not released to `main`
Telemetry and launcher (plugin #6)	`dispatch.sh` forwards `OTEL_` and `AGENTDOCK_` to workers and tags each with project, slot, issue and run; `CS_CLAUDE_BIN` picks the `claude` executable	merged on `develop`, not released
`specDir` outside the repo (plugin #7)	Spec files in a separate docs repository	merged on `develop`, not released
Init template password (plugin #9)	`init` reads the database password from an env file	merged on `develop`, not released
Merge approval (plugin #8)	Honour `mergeApproval` and approval decisions	on an unmerged branch
Repo in session names (plugin #11)	`cs-<repo>-<slot>` sessions, so two orchestrators on one machine do not see each other's slots	open; AgentDock already accepts both forms
Codex workers	`dispatch.sh --runtime codex` and a pre-merge ownership check	not started (AgentDock milestone M4)

Released plugin versus develop

The plugin's main branch (version 1.24.0 at the time of writing) has none of the develop changes above. If you install from the marketplace today, AgentDock runs in fallback mode, described below.

Fallback mode

With a plugin that does not write events.jsonl, AgentDock reads the fleet from markdown and tmux instead: round boards, briefs, reply files, pane contents, worktrees and gh output. Everything on the Fleet, Queue and History pages still works. Data that came from scraping carries a scraped badge in the UI.

When the plugin does write structured events, the runner tails events.jsonl, snapshots state.json on connect, and plugin facts win over scraped ones. A project can show both channels at once during the switch.

Two things are weaker in fallback mode:

Live cost for workers. Without plugin #6, workers do not get AgentDock's OpenTelemetry tags. Their cost is still computed afterwards from session transcripts.
Custom launcher for workers. Workers already inherit the orchestrator's CLAUDE_CONFIG_DIR, so they run on the same Claude profile. A different claude executable (CS_CLAUDE_BIN) needs plugin #6.

Next steps

Orchestrator workflowFrom a ready issue to a merged pull request.Specs and grillingTurn an idea into an issue the fleet can build.Config referenceEvery key of the orchestrator block.Fleet and live paneSteer the orchestrator from AgentDock.