dkj-subagents-ecomm

v5.6.0

Add-on team for commercial webshop repos (any platform): the SEO specialist Sergio, the CRO specialist Craig, and the performance/SEA specialist Sean, with room to grow into the wider e-commerce craft (lifecycle/email, analytics). Deliberately NOT repo-neutral — only a commercial webshop repo enables this team. Teams stack: platform-agnostic, so it sits alongside a platform team like 'dkj-subagents-shopify' rather than replacing it. The governance layer (CLAUDE.md + the repo lenses) and the core team ('dkj-subagents-alpha') stay separate.

Claude Code

By DaveKJohn1 GitHub starsUpdated yesterday

Directory evidence

Runtimes: Claude Code
Parsed components: 0 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-ecomm 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-ecomm@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-ecomm/.

Plugin files

plugins/dkj-subagents/dkj-subagents-ecomm/

└── .claude-plugin/plugin.json

Plugin manifests1

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

{
  "name": "dkj-subagents-ecomm",
  "displayName": "Claude Specialists — team e-commerce (subagent scaffold)",
  "description": "Add-on team for commercial webshop repos (any platform): the SEO specialist Sergio, the CRO specialist Craig, and the performance/SEA specialist Sean, with room to grow into the wider e-commerce craft (lifecycle/email, analytics). Deliberately NOT repo-neutral — only a commercial webshop repo enables this team. Teams stack: platform-agnostic, so it sits alongside a platform team like 'dkj-subagents-shopify' rather than replacing it. The governance layer (CLAUDE.md + the repo lenses) and the core team ('dkj-subagents-alpha') stay separate.",
  "agents": [
    "./subagents/specialist-06-26-subagent.md",
    "./subagents/specialist-06-27-subagent.md",
    "./subagents/specialist-06-28-subagent.md"
  ],
  "version": "5.6.0",
  "author": {
    "name": "DaveKJohn"
  },
  "keywords": [
    "specialists",
    "team",
    "claude-code",
    "ecommerce",
    "seo",
    "cro",
    "sea",
    "webshop"
  ]
}

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-ecomm on Agent Plugins Marketplace](https://pluginsmp.com/plugins/dkj-subagents-ecomm)