opt-in plugins

by vikash ruhil

Loomwright is a plan-first, multi-agent development system for Claude Code. Launch Pad turns a goal into a reviewed brief; Supervisor executes it autonomously across parallel git worktrees with self-heal; dedicated agents cover code review, red-teaming, QA, and standalone PR review-and-heal. 14 agent roles, 24 slash commands, 42 skills, 39 quality gate hooks. Full history in CHANGELOG.md.

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.

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.