claude-code-plugins

Use to create or update the per-author Ghost style guide from all available signals — interview answers, reference docs, and the published corpus — and to fold a newly approved post into it. Triggers on "build my style guide", "update the style guide", "learn my voice from my posts", and is invoked by push-draft after a successful push.

Use to write the first full draft of a Ghost blog post locally, matching the author's style guide, then self-audit it against the anti-pattern checklist. Triggers on "draft a post about X", "write the first draft", "start a new blog post".

Use to revise an existing local Ghost draft section by section with the author, improving formatting, voice, and accuracy. Triggers on "revise this post", "let's go through it section by section", "tighten this draft".

Use when first connecting a project to a Ghost site for the ghost plugin, or whenever Ghost credentials are missing/unverified — onboards the Ghost Admin API key, enables the plugin at project level, and verifies the connection. Triggers on "set up ghost", "connect my ghost site", "ghost credentials", "the ghost mcp isn't working".

Use to push a finished local Ghost draft to the Ghost site as a draft (never published) — pull-guards against in-editor edits, uploads the feature image, creates or updates the post, verifies links, and feeds the approved post back into the style guide. Triggers on "push this to ghost", "send the draft to ghost", "publish to ghost as a draft".

Use to write a Ghost blog post end to end, walking the full plan→draft→revise→push flow in one guided pass. Triggers on "write a post about X end to end", "take this from idea to a ghost draft", "guide me through writing a post".

Use when establishing or refining how an author wants to sound before writing Ghost posts, especially with no published corpus yet (cold start) — interviews the author about audience, tone, and admired references, and gathers reference material to seed the style guide. Triggers on "define my voice", "set up my writing style", "I'm starting a new blog", "here are posts I like".

Use when bootstrapping a new repo's CI, setting up deploy workflows, deciding what branch a feature PR should target, or whenever someone proposes "auto-deploy prod on every main merge". Captures the feat → dev → main promotion model with separate Deploy Dev (push to dev) and Deploy Prod (push to main), and links the templates that implement it.

Use when about to make code changes while other work is in flight, when working in a repo's primary clone with live git worktrees, when starting a parallel line of work, or when dispatching agents that write to the tree. The rule — the primary clone is a coordination point, not a workspace; isolate every line of work (yours and agents') in its own git worktree so parallel lines never collide in one tree.

End-to-end autopilot for driving a captured feature from idea.md through to merged PR. Chains feature-plan, feature-review-plan, feature-implement, feature-review-impl, and feature-ship with reviewer gates between phases. Auto-advances on PASS/CONDITIONAL PASS, pauses on FAIL. Use when the user says "ship feature X", "autopilot X", "drive X end-to-end", or hands over a feature ID with intent to complete it.

Initialize feature-workflow for a project, or refresh CI files with --update. Creates docs/features/, .feature-workflow.yml, and optional GitHub Actions review setup.

Complete a feature by writing shipped.md, committing to the feature branch, and merging the PR. Use when external reviews are done and the feature is ready to ship.

Apply project-workflow standards to a repo — feat → dev → main promotion model + CI gate, GitHub repo setup (branch protection, environments, secrets, OIDC), and the quality stack (skylos/fallow via lefthook + a shared justfile, run identically in CI). Detects current state and applies only the *missing* patterns, so it works on both new repos and existing ones. Use when setting up a new project or bringing an existing one up to standard.

Interactive workflow for adding items to the backlog. Use when user wants to add a new feature, track an idea, capture requirements, or mentions something that should be in the backlog.

Coordinate a multi-repo deploy across a workspace's member repos in producer-first order. Use after a cross-repo epic's children have all merged and you need to release the members in dependency order (e.g. deploy the API producer before its consumers).

Submit a feature implementation for external review via the existing draft PR, or respond to reviewer feedback on the code. Pushes implementation to the feature branch and updates the PR.

Submit a feature plan for external review via draft PR, or respond to reviewer feedback on the plan. Creates a feature branch, opens a draft PR containing the plan, and manages the review cycle.

Use when setting up a repo's lint / static-analysis / test tooling — wiring lefthook git hooks (pre-commit auto-fixers + pre-push full verify) and a justfile that is the single source of truth both the hooks and CI call, so local checks and CI can't drift. Language-agnostic: ruff/skylos for Python, prettier/eslint/fallow for TS/JS, same pattern for any language. Installs the tooling; ongoing operation lives in quality-workflow (/quality-audit, /quality-unblock, /quality-verify-hook) and the standing suppression rule in suppression-discipline.

Use whenever build, deploy, or background code reads files from another GitHub repo at runtime — workshop content, manifests, configs fetched from a registry. Captures the rules that keep us under the GitHub App's 15000/hr installation rate limit (zipball over per-file, respect retry-after, share fetched content) and links the reference implementation.

The standard for how a repo is laid out and how files/modules are named, so every project looks the same and generated code has an obvious right place. Use when creating a new file, module, or directory, deciding where something goes, naming a file/folder, scaffolding a new repo, or reviewing whether code is well-organized. Counters the AI-slop failure mode of sprawling, inconsistently-placed, god-everything files.

Use when bootstrapping a new repo's GitHub-side setup — branch protection / rulesets, deploy environments, environment secrets, OIDC cloud auth, or required reviewers — or whenever deploy workflows reference secrets.* / environment: that don't exist yet. Captures the repo settings that make the feat → dev → main promotion model *enforced* rather than convention, and scopes deploy credentials to the environment that gates them.

Triage a failing pre-commit hook (skylos or fallow). For each finding, look up the rule in the day-1 playbook and present three options — fix in code, suppress with a required

Verify that a project's static-analysis git hooks actually fire on bad code — works with lefthook or the pre-commit framework. Use after installing the quality stack (lefthook install), after editing lefthook.yml / .pre-commit-config.yaml, or whenever the user asks "is the hook working?" / "test the hooks" / "verify hooks". Stages known-bad fixtures and asserts non-zero exit; stages known-good fixtures and asserts zero exit. The hook silence-equals-working failure mode is the whole reason this plugin exists.

The rule for suppressing static-analysis findings in any language — every suppression carries an inline rationale, and bare suppressions are a quality failure to fix. Use when someone adds or proposes a lint/analysis ignore (# skylos: ignore, # noqa, # type: ignore, # fallow-ignore, // eslint-disable, @ts-ignore, #[allow(...)], //nolint, etc.), proposes bypassing hooks with --no-verify, or when reviewing code that contains suppressions. Complements /quality-unblock, which triages a failing hook and enforces the per-PR cap.

Read-only static-analysis snapshot. Runs skylos (Python) and fallow (TS/JS) full audits, writes a fingerprinted snapshot to .claude/quality-snapshots/YYYY-MM-DD.json, and renders a grade card plus delta vs the previous snapshot (NEW / RESOLVED / PERSISTING findings). Use when the user asks "what's my code health?", "run skylos", "run fallow", "audit quality", "snapshot quality", or after a cleanup pass to confirm wins.

Check project backlog when discussing feature ideas or priorities. Use when user mentions adding features, asks what's planned, discusses priorities, or proposes new functionality. Silently reads DASHBOARD.md to show relevant items and suggest /feature-capture for untracked ideas.

Execute a feature implementation plan from a clean context. Use when starting implementation after planning, or when resuming work on an in-progress feature. Reads plan.md and executes implementation steps.

Start implementing a feature from the backlog with adaptive agent dispatch. Use when user wants to begin work on a backlog item, start implementation, or mentions a specific feature ID to work on.

Search and filter features by state, assignee, priority, epic, dependency, type, or category. Use when the user wants to find features matching criteria — "what's paused", "what's court working on", "what's in the auth-overhaul epic", "what depends on X".

Change a feature's state (active/paused/replaced/abandoned). Use when a feature needs to be paused while waiting on something, marked obsolete because another feature replaces it, or abandoned because it won't be pursued. Requires companion fields for non-active states.

Display project status and backlog overview. Use when user asks about current status, what's in progress, what to work on next, or wants a summary of the backlog. Read-only skill that formats DASHBOARD.md into a clear dashboard view.

Update feature progress log and check off completed tasks. Use when user completes implementation tasks, makes commits, or indicates work is done. ASKS BEFORE MODIFYING files. Updates plan.md progress log section and implementation step checkboxes.

Interactive onboarding for someone who just cloned the claude-code-plugins repo and wants to install the feature-workflow plugin into their own project. Use when the user asks "how do I use this", "where do I start", "walk me through it", wants a demo, or is evaluating the repo. Explains what this repo is, helps install the plugin from this marketplace, then guides a live end-to-end walkthrough.

Generate a structured team assignment message from the current sprint plan. Produces a copy-pasteable message for Slack, email, or team chat with per-person assignments, context blocks, and key ground rules. Use after sprint-plan to share assignments.

Audit all assigned feature specs for completeness. Checks that every developer has enough information to work independently — domain context, file paths, code maps, realistic examples, and clear deliverables. Flags gaps and offers to fix them. Use after sprint-plan, before sharing assignments.

Create a weekly sprint plan from backlog and deadline. Triages features into deadline buckets, assigns owners by expertise lane, identifies critical path, and produces a shareable plan file. Use when starting a new sprint or preparing for a demo/release.

Sprint retrospective — review what was planned vs. accomplished, capture lessons learned, identify what worked and what didn't. Use at the end of a sprint or after a deadline event (demo, release). Produces actionable takeaways for the next sprint.

Focused backlog triage — categorize features into deadline-critical, this-sprint, and post-deadline buckets. Removes stale items, verifies PR/merge status, and produces a clean prioritized list. Use when the backlog needs cleanup before planning.

Adds Cognito authentication and route protection. Use when adding login, signup, authentication, or user management.

Adds DynamoDB database persistence to the application. Use when the app needs data storage or persistence.