dkj-subagents-alpha

v5.6.0

Portable executable core of the Claude Specialists system: the shared subagents plus the portable persona templates (personas/) of the main-loop specialists and the generic bootstrap skill specialists-init. This is the team every consuming repo enables; the other teams add to it, they do not replace it. Deliberately contains NO safety/guardrail hooks and NO repo-SPECIFIC skills — the governance layer (CLAUDE.md + repo lenses), the safety hooks, and the repo's own specialists stay at repo level. Two deliberate, repo-neutral exceptions: the skill specialists-init (the adoption path itself) and the informational SessionStart hook roster-sessioncheck (hooks/, read-only, never blocks).

Claude Code4 Skills

By DaveKJohn1 GitHub starsUpdated yesterday

Directory evidence

Runtimes: Claude Code
Parsed components: 4 skill or MCP entries
Source updated: Sep 22, 2026
Manifest status: Canonical path parsed

The directory validates manifest shape and source location. It does not execute the plugin or provide a security endorsement. Review the indexing methodology →

Install dkj-subagents-alpha for Claude Code

Installs for the current user

claude plugin marketplace add IchenDEV/agent-plugin-mkt
claude plugin marketplace update agent-plugin-marketplace
claude plugin install dkj-subagents-alpha@agent-plugin-marketplace

Paste and run these commands in a terminal with Claude Code. They add and refresh the PluginsMP catalog, then install this plugin.

The installer fetches third-party code from the source repository shown on this page. This directory validates manifest structure and source location, but does not perform a security audit; review the manifest, components, and source before installing.

Get the source manually

$ git clone https://github.com/DKJ-Solutions/dkj-claude-plugins

Clone the source repository, then follow its setup instructions to add the plugin to a compatible client. The plugin root is plugins/dkj-subagents/dkj-subagents-alpha/.

Plugin files

plugins/dkj-subagents/dkj-subagents-alpha/

├── .claude-plugin/plugin.json
├── skills/orchestrator/SKILL.md
├── skills/specialists-init/SKILL.md
├── skills/specialists-teardown/SKILL.md
└── skills/sync-roster/SKILL.md

Included Skills4

orchestratorskills/orchestrator/SKILL.md

Load Chris, the Chief of Staff, into this conversation: the orchestrator who classifies an assignment, names the specialist it belongs to, and closes it out. Use this in a session where his usual route is not available -- a repo that has not run `specialists-init` yet, no repo at all, or a fresh conversation in an app where the specialists arrived as subagents without a conductor. Before that bootstrap nothing else in context carries his rules for filing what you find or for verifying a refusal before you obey it. In a repo that has run `specialists-init` he is already loaded and this skill has nothing to add.

specialists-initskills/specialists-init/SKILL.md

Bootstrap the Claude Specialists system in a new consuming repo: hook up the orchestrator (Chris) via one @-import in CLAUDE.md pointing at the seam (which in turn imports his portable body from the plugin install + his lens-only repo lens), put the plugin's other main-loop personas and the subagents in place as lens-only scaffolds in the seam plus the script-config scaffolds, and deliver a governance/safety-hooks proposal. Use this when the shared `dkj-subagents-alpha` plugin is installed and enabled but the conductor and the governance layer are still missing ("the workers are there, Chris is not").

specialists-teardownskills/specialists-teardown/SKILL.md

Remove what specialists-init put into a consuming repo, so the repo can stand free of the plugin: the generated lens scaffolds, the one @-import in CLAUDE.md plus the two inside the seam, the untouched script-config scaffolds and the settings proposal. Strictly subtractive and the mirror image of the bootstrap -- it never deletes anything the repo owner filled in, and never edits settings.json. Dry run by default. Use this when a consumer is being disconnected from the plugin, or to verify that adoption is genuinely reversible before relying on it.

sync-rosterskills/sync-roster/SKILL.md

Stage the roster-sync catch-up after the roster-sessioncheck hook flags that a specialist is missing from this repo's roster/lenses. Creates the empty repo-lens scaffolds (additive, never overwriting) and prints proposed roster rows ready to paste -- it never writes to CLAUDE.md, never commits, and never touches a branch. Use this when the SessionStart roster check reports drift and the mechanical part of the recovery should be staged automatically.

Plugin manifests1

plugins/dkj-subagents/dkj-subagents-alpha/.claude-plugin/plugin.json

{
  "name": "dkj-subagents-alpha",
  "displayName": "Claude Specialists — team alpha (the core team, subagent scaffold)",
  "description": "Portable executable core of the Claude Specialists system: the shared subagents plus the portable persona templates (personas/) of the main-loop specialists and the generic bootstrap skill specialists-init. This is the team every consuming repo enables; the other teams add to it, they do not replace it. Deliberately contains NO safety/guardrail hooks and NO repo-SPECIFIC skills — the governance layer (CLAUDE.md + repo lenses), the safety hooks, and the repo's own specialists stay at repo level. Two deliberate, repo-neutral exceptions: the skill specialists-init (the adoption path itself) and the informational SessionStart hook roster-sessioncheck (hooks/, read-only, never blocks).",
  "agents": [
    "./subagents/specialist-02-09-subagent.md",
    "./subagents/specialist-03-07-subagent.md",
    "./subagents/specialist-04-11-subagent.md",
    "./subagents/specialist-04-12-subagent.md",
    "./subagents/specialist-04-13-subagent.md",
    "./subagents/specialist-04-18-subagent.md",
    "./subagents/specialist-05-15-subagent.md",
    "./subagents/specialist-06-16-subagent.md",
    "./subagents/specialist-06-17-subagent.md",
    "./subagents/specialist-06-19-subagent.md",
    "./subagents/specialist-06-23-subagent.md",
    "./subagents/specialist-06-24-subagent.md",
    "./subagents/specialist-06-25-subagent.md",
    "./subagents/specialist-06-29-subagent.md",
    "./subagents/specialist-06-30-subagent.md"
  ],
  "version": "5.6.0",
  "author": {
    "name": "DaveKJohn"
  },
  "keywords": [
    "specialists",
    "team",
    "claude-code"
  ]
}

Browse the “specialists” tag →

agent-dispatcher

by nahid

Routes each request to one of 27 specialist agent roles, which load only the skills the work needs and verify what they claim.

Claude Code1 Skill

46Updated yesterday

dkj-policy

by DaveKJohn

One particular way of working, packaged so a repo can choose it: the branch-and-entry model, the tier ladder, the fold, the release cut and the gates that hold them, as skills plus their shared scripts. A workflow is not a team — it changes how the specialists work, not who they are — and the name says whose it is on purpose: DKJ's policy, the top rung of the order, not a baseline every consumer inherits. Deliberately NOT part of the core: a consuming repo is unique and has its own way of working, and the specialists adapt to it. Enable this only if you want THIS way of working. Requires the core team 'dkj-subagents-alpha', and a repo-side scripts/repo-config.ps1 + scripts/lib/branch-info.ps1.

Claude Code19 Skills

1Updated yesterday

dkj-policy-bwj

by DaveKJohn

The shared law layer for BWJ's two Shopify stores (smartwatchbanden and xoxowildhearts), packaged so both repos run one identical procedure and cannot drift on it. Four chapters. TICKET HANDLING: a discovered issue is created on GitHub first (GitHub is the source of truth), then mirrored to Asana as a colleague-friendly variant, cross-linked both ways; closing the GitHub issue makes a CI workflow post an update saying the work is ready to test and move the card, never ticking the task off - only the colleague who asked for it can do that. THE SYNC LOG: a 'sync/' branch mirrors what a third party changed on the live theme, is exempt from the changelog by design, and therefore owes a sync-log entry instead - dkj-policy-bwj/SYNC-LOG.md, newest at the top, written and committed by dkj-subagents-shopify's sync-main.ps1 in the same breath as the branch, never folded and never released. THE PREVIEW HANDOVER: where a preview is owed, it is a PAIR per market - the preview beside the live control, whose URL pins the live theme id, because preview_theme_id sets a cookie and the bare URL then keeps serving the preview while the reviewer believes they are looking at live. That pair travels as ONE link to a published page carrying a QR code per market, plus what the gates already proved and the one question being asked - never as a table of URLs, which a terminal wraps past selecting and a phone cannot scan. THE THEME LIFECYCLE: the estate owes two things at the two moments it grows - after the live push, the spent preview themes THIS repo created are swept away; at the release cut that closes that push, a fresh backup of live is taken, polled until it is provably complete (the CLI returns long before the copy is), and only then is the previous backup rotated out, so exactly one is retained and there is never a window with none. Every delete is bounded by a reserved name prefix this repo wrote, never by a theme's role: a store carries far more themes belonging to agencies, apps and colleagues than to the repo, and a role-keyed sweep would destroy them all while looking correct. It relaxes nothing about which changes owe a preview, or about no PR opening before one is approved - it tightens both, by adding exactly TWO steps to that workflow's cycle and changing nothing before the step list. The last step under '### CREATE' is always 'Is the change visible in the frontend / storefront?': dropped with its reason where nothing renders, and otherwise a preview theme, a comment on the GitHub issue carrying the steps and every URL, and ticked only once a PERSON confirms they looked - being last is what makes dkj-policy's own step-list gate hold the PR until then, since an agent can prove a theme exists and never that somebody looked at it. And just before the issue is closed, the paste-ready block gains its go-live half: the next release day (BWJ cuts on Mondays), the version that release is on course for, and the live storefront URL per market - written by build-golive-block.ps1, worded as a plan rather than a promise, and leaving out any fact it cannot derive instead of guessing one. It is an ADDITIVE add-on to 'dkj-policy', not a replacement: it extends four seams of that workflow - the ticket-work layer before a branch, what a sync branch owes, how a preview is handed over, and what the theme estate owes at a push and a cut - and says nothing about branch naming, what an ordinary change owes before a PR, or what a release is. Every chapter is policy rather than mechanism: the Asana CI lives in each repo's .github/, and the sync and preview machinery in 'dkj-subagents-shopify'. Requires the core team 'dkj-subagents-alpha' and 'dkj-policy'; the sync and preview chapters also expect 'dkj-subagents-shopify'. Enable this in BWJ's two Shopify store repos for all four chapters, or in this plugin's own source repo for ticket handling alone (admitted September 14, 2026, commit b9b2a65a) -- the other three chapters are Shopify-store policy and stay at the two stores.

For maintainers

If you maintain this plugin, link to this source-backed listing from your README so users can review its manifest and indexed components.

[dkj-subagents-alpha on Agent Plugins Marketplace](https://pluginsmp.com/plugins/dkj-subagents-alpha)