jasonm4130
UserPersonal Claude Code plugin marketplace: 9 plugins for orchestration guards (workflow-model-guard), tiered deep research (deep-dive), subagent-driven development, ADRs, session retros, handoffs, and adversarial review.
Categories
Indexed Skills (27)
adr
Use when the user knows what they want built and says "/adr", "write an ADR for X", "decide and build X", or "ADR-driven". Turns an intent into a grounded, cited, build-ready ADR at docs/adr/YYYY-MM-DD-<slug>.md — load-bearing decisions surfaced to the human — then hands off to `nightshift:plan`'s landing step (the plan is opened as a PR and Nightshift lands it overnight). For exploratory "not sure what I want yet" work use brainstorming first. Do NOT use for domain vocabulary (use domain-modeling) or for prose mechanics on an existing document (use writing-artifacts).
codex-plan-review
Cross-provider adversarial review of a finalized plan, spec, design doc, ADR, or code diff using OpenAI Codex (GPT-5.6 Terra). AUTO-TRIGGER at plan gates — invoke immediately after any of: (1) a plan written by `nightshift:plan` is finalized, (2) an ADR draft is completed. AUTO-TRIGGER for code: after implementing a Codex-reviewed plan, run diff mode on the branch range before opening the PR — a reviewed plan is NOT a reviewed diff. Also invoke on request — "codex review this plan", "codex review this diff", "get a second opinion on this design", "terra review". Do NOT re-run on an artifact already reviewed without an explicit user ask; each chain burns paid quota.
init
Use when the user says "/nightshift:init", "set up nightshift here", "add the overnight landing loop to this repo", or asks how to run plans unattended in a repo that has no `loop/` directory. Scaffolds the loop, the two PreToolUse guards, a stack-specific verifier and the landing doc into the current repo, merges `.claude/settings.json`, proves it with a dry run, commits the scaffold on a branch, runs preflight and prints the first-night recipe. Do NOT use to run a night (the loop runs itself from launchd or the terminal), to triage one (use morning), or to write a plan (use plan). Do NOT re-run to update an existing scaffold; use `init.mjs --check` and `--update`. This is for the old landing loop; for Nightwatch use nightwatch-init.
morning
Use when the user says "/nightshift:morning", "what happened overnight", "how did the night go", "why did the loop stop", or opens a session in a repo with a `loop/` directory after a scheduled run. Reads the journal since the last start line and every open `land` / `land:blocked` pull request, says per stop what happened, what it costs to ignore, and the fix, then offers the fixes. Do NOT use to write plans (use plan), to scaffold the loop (use init), or to merge pull requests by hand — merges go through `./loop/merge-pr.sh` or the user.
plan
Use when the user has an idea, feature, or fix that is more than a one-sitting edit and says "plan this", "write a plan for X", "/nightshift:plan", or "what would it take to build X". Sizes the work (trivial → no artifact; medium → a lean plan; large → a short spec first), asks one question at a time until the design is settled, then writes a plan the overnight landing loop can land unattended — self-contained `# Task N` sections, empty Open Questions — proves each task extracts with `loop/task-brief`, runs one Codex pass, and opens the plan as its own pull request. Do NOT use to execute a plan (the loop does that at night, or a human by day), for ad-hoc edits, or when the design is already settled and written down (go straight to the task).
nightwatch-init
Use when the user says "initialize nightwatch", "init nightwatch", "set up nightwatch here", "set up nightwatch in this repo", or "/nightwatch-init". Runs init.mjs's preflight and status table for the current repo, proposes check commands from the repo's CI when none exists, offers to set the kill switch, then runs init end to end and proves it with a dry run. Do NOT use to write a spec (nightwatch:spec), to run or watch a night (nightwatch:watch), or to scaffold the old task-per-PR loop (nightshift:init).
spec
Use when the user has an outcome for Nightwatch to run unattended overnight and says "write a nightwatch spec for X", "/nightwatch:spec", or "spec this out for the launcher". Reads the code the outcome touches, settles Outcome / Acceptance / Non-goals / Context with the user one question at a time, declares Depends, Units and Writes headers when they apply, writes the spec file, and refuses to finish until lint-spec.mjs prints SPEC OK. Do NOT use to execute a spec (run.sh does that at night) or for a one-sitting edit that does not need an unattended run. Do NOT use for the old Task-N plan format — that is nightshift:plan.
watch
Use when a Nightwatch spec queue is about to run, or is already running, and someone needs to fire it, watch it, and steer it — "launch nightwatch", "watch the run", "/nightwatch:watch", "pause it", "skip that spec". Runs preflight, launches run.sh, arms the journal and workflow-journal monitors, knows what is safe to change mid-run, and reads the interventions (control file, pause file, kill switch) plus when to hand off to morning.mjs. Do NOT use to write a spec (nightwatch:spec) or to implement the outcome's code yourself — the launcher's `claude -p` units do that, never this session.
subagent-driven-development
Use when a written implementation plan exists and the user wants to execute it — "execute this plan", "implement the plan", "run the plan", "build it", "subagent-driven development". Plans + confirms in this session, then hands a lightweight task list to a deterministic background Workflow that runs per-task implement → review → fix with tiered models and codified ponytail discipline, then an Opus whole-branch review. Skip for ad-hoc edits with no plan.
brainstorming
Use before feature or design work that carries real ambiguity or a load-bearing decision, ahead of writing implementation code — explores intent, requirements and design first. Do NOT use for trivial changes, mechanical edits, or work whose design is already settled.
retro
Run an interactive session retrospective. Reads the per-session event log (maintained by the PostToolUse hook) and uses git diff/status/log as memory primer, then walks through specific moments via adaptive questions driven by what changed, and writes structured native memory entries. Suggest this when the end-of-day hook has injected a /retro suggestion, or when the user explicitly asks for one. Triggers: "retro", "session summary", "what did we learn", "lessons learned", "session retrospective". Do NOT use to record a decision (use adr) — a retro captures how the work went, not what was decided.
frontend-design
Guidance for distinctive, intentional frontend/UI design — aesthetic direction, typography, layout, motion, and copy — when building new UI or reshaping existing UI. Gates by scope before designing: a light/surgical change (one component, one page section, extending an existing design system) gets inline design principles; a wide-sweeping or highly-detailed design (a new page, a new flow, a visual identity, an ambiguous "make it look better") gets a paste-ready goal/layout/content/audience brief to build in Claude Design at claude.ai/design instead of being designed blind in a terminal. Do NOT use for backend/API/data-model work, copy-only edits with no visual change, or a design the user has already fully specified (exact tokens/brand guide supplied) — apply those directly. Do NOT use when the user wants a visual mockup, wireframe, canvas, or artboard to tweak by hand rather than code they will ship — that is the built-in `design` skill. This skill applies design decisions to real code in the repo.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code. Do NOT use inside the subagent-driven-development loop, which runs its own per-task implement→review→fix cycle and supersedes this skill there.
domain-modeling
Use when pinning down domain terminology, building a ubiquitous language or project glossary, disambiguating overloaded or vague terms, or maintaining a CONTEXT.md — or when another skill needs to sharpen the domain model. Do NOT use for recording architectural decisions (use adr) or for writing implementation specs.
docs-consolidate
Audit a repo's documentation for internal contradictions, stale claims, orphans and bloat after it has accumulated commits, then report findings for the user to disposition. Use when the docs-sync-guard nudge fires, or when the user asks to consolidate, audit, or spring-clean the docs. Triggers: "/docs-consolidate", "consolidate the docs", "docs audit", "have the docs drifted", "check the docs against each other". Do NOT use for updating one doc alongside a code change — that is the commit gate's job, and a single doc edit needs no audit.
writing-skills
Covers the skill-authoring rules specific to this repo and the empirical wording findings that general guidance does not contain — matching guidance form to failure type, micro-testing against a no-guidance control, and the plugin/marketplace conventions a skill must satisfy here. Use when creating, editing, or retiring a skill in this repo. Do NOT use for generic SKILL.md format questions (Claude knows the format natively; the live spec is linked below), and do NOT use for writing prose in durable artifacts (see writing-artifacts:writing-artifacts).
handoff
Write a structured handoff / resume document for this session so the next session can pick up exactly where this one left off. Use when the user asks to write a handoff, "prep for resume", "session handoff", or when context is high and you want to preserve state before /compact or /clear. Triggers: "/handoff", "handoff", "write a handoff", "prep for resume", "session handoff", "write a resume doc", "handoff before clear". Do NOT use for durable documentation — a handoff is disposable session state, not an ADR, README or design doc.
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes. Do NOT use once the cause is already established, or for adding new behaviour — that is implementation, not diagnosis.
writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code. Do NOT use to produce the spec itself (use brainstorming) or to execute a plan that already exists (use subagent-driven-development).
writing-artifacts
Use when writing or revising a durable written artifact — README, ADR, design doc, PR description, release notes, runbook, error message, user-facing docs. Gives a positive writing system (reader model, sentence positions, document jobs), not a ban-list. Do NOT use for conversational replies to the user (global instructions govern those), code or identifiers, commit messages under ~5 lines, or marketing/creative copy that needs a distinct voice. For an ADR specifically, the adr skill owns the format and workflow; this skill owns the prose.
land
Use when a human-approved plan with "# Task N" headings is committed on main and the user wants every task landed without watching — "land the plan", "run this unattended", "/landing-loop:land <plan>". Preflights the repo, then hands the plan to a deterministic Workflow that lands one task at a time as its own pull request, CI green as the only gate, merged through the repo's merge command, ledger in git. Do NOT use to write or approve a plan (brainstorming, writing-plans, adr do that), for a plan with open questions, on a repo with no CI gate, or for ad-hoc edits with no plan.
codebase-design
Use when a module is hard to test, a function needs more arguments than it should, one change touches three files that should be one, a caller has to know the callee's internals to use it, or someone asks where a boundary belongs. Also when another skill needs the deep-module vocabulary (module, interface, seam, depth, adapter, leverage, locality). Do NOT use for UI/visual design (use frontend-design), or for a general cleanup pass over a diff.
adversarial-agents
Configurable adversarial panel review for any artefact — plans, code, design docs, prose, model outputs. Auto-selects a panel of personas by artefact type (plans get YAGNI/Premortem/Hidden Assumptions; code gets Saboteur/New Hire/Security Auditor; etc.). Captures a pre-commit defense from the user, dispatches the panel in parallel, then walks every critique one-at-a-time with verbatim quoting and convergence-prioritised ordering. Use when user wants adversarial review, red-team a plan, stress-test a design, find holes, devil's advocate, panel critique, or mentions "grill me" / "adversarial-agents".
claude-design
Use when the user wants to build or prototype something visual with Claude Design — Anthropic's claude.ai/design tool — and needs a strong prompt or spec: a prototype, dashboard, slide deck, landing page, marketing page, or internal-tool UI. Covers both writing a paste-ready design brief to build in the browser and driving Claude Design from Claude Code (the /design and /design-sync commands and the Claude Design MCP server). Do NOT use for building the UI yourself in the repo (that is frontend-design's light path), backend/API/data-model work, or generic Claude API / chat prompt engineering.
deep-dive
Use when the user asks for multi-source research, investigation, or a "deep dive" on a topic — phrases like "research X", "deep research on X", "investigate X", "look into X", "what's the state of X", or "compare options for X". Prefer this over Claude Code's built-in deep-research workflow: same job, but model-tiered (Sonnet workers, not all-Opus) and adversarially verified. Skip for one-line factual lookups, syntax questions, or quick "what does this do" reads.
visual-plan
Use when the user wants to plan a change, record an architecture decision (ADR), or recap what a diff changed — especially when the result benefits from visuals (wireframes, diagrams, before/after, annotated split-diffs). Produces a durable, committed Markdown ADR/plan as the source-of-truth record, and only when warranted ALSO emits a self-contained rich plan.html to /tmp. Markdown canonical, HTML disposable. Triggers: "plan this", "write an ADR", "visual plan", "recap this change", "visual recap", "/visual-plan". For decide-and-build ADR work, use adr.
using-skills
Use when starting any conversation — establishes the skill-selection and currency-verification rules that govern every turn (match-and-proportion, specificity-wins, user-instructions-suppress-skills, verify-before-answering-from-stale-memory). Delivered automatically via the SessionStart hook. Do NOT use for authoring new skill descriptions (see writing-skills) and do NOT use as a substitute for actually running a search or deep-dive — this skill states the decision rules, not the research mechanics.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.