idea-to-prod

Plugin idea-to-prod from marketplace skills in mattbutlerengineering/skills. Commands read from the repo's manifest — yesterday.

Skills (31)

• animated-diagram

  Generate an ambient animated diagram as one self-contained dark-mode file — .html with a pause control, or a pure .svg whose SMIL/CSS motion plays right inside a GitHub README image embed — an inline-SVG flow or architecture picture whose dashed connectors stream in the direction of execution and wh

• architect

  Use when requirements exist and the technical design is needed — architecture, data model, stack, interfaces — or when the user asks for technical design directly. Drafts from artifacts and codebase, then asks only about trade-offs. Produces architecture.md.

• assembly-line

  Generate the assembly line — one self-contained animated HTML page that draws every run in the current repo as a crate on an isometric factory floor, one machine per pipeline stage, finished runs raising a named building each in the city at the end of the line, hover and click detail on every statio

• audit

  Use when the ask is to go looking for what to improve in a codebase — "audit this repo", "find the bugs / security holes / tech debt / coverage gaps", "what's rotting here", "where should we take this next", "what should I work on" — with no defect named and no run in flight. Read-only on source, al

• automate

  Use when the ask is what Claude Code automation a repo should have — "what hooks should I add", "should this be a skill or a subagent", "recommend automations for this project", "what's worth automating here", "is there an MCP server worth wiring up". Read-only; it recommends, prices, and hands off

• autorun

  Use when the user wants a whole run driven end to end from a one-time brief — they supply the feature description and answers to the big questions up front, then an orchestrating agent advances the run from idea through ship, one fresh subagent per stage, answering each stage's interview from the br

• capture

  Use when the user reports a bug, defect, or regression to fix, or wants to start a refactor or dependency upgrade as a tracked maintenance run — not a new feature, and no fix artifacts exist yet. Interviews the user and produces the defect brief (defect.md) that seeds the run and records its re-entr

• conduct

  Use when the Owner wants several of their own GitHub issues taken from plan to merged as one batch — "run these issues as a batch", "conduct these five issues", "fan these out and merge them in order", "pick the batch back up", or a direct invocation. The Owner's session becomes the Conductor. It pr

• decompose

  Use when a technical design exists and needs breaking into ordered, implementable work items — milestones, dependencies, sequencing — or when the user asks to break the work down. Drafts from the architecture. Produces breakdown.md.

• deepen

  Use when the question is the shape of existing code rather than a defect in it — "improve the architecture", "find refactoring opportunities", "this is hard to test", "these modules are too coupled", "make this codebase easier for an agent to navigate". Reviews a codebase for deepening opportunities

• doctor

  Use when the question is whether the pipeline itself is installed correctly in this repo — "is any of this actually wired up", "did the factory stamp take", "make check fails on a fresh stamp and it looks like the tool is broken", "are the skills even installed", "check the CODEOWNERS/labels/workflo

• factory-init

  Use when a repo needs the factory tooling stamped in or the template checksum manifest regenerated — setting up a product repo to take factory work orders (Makefile check target, gate detectors, factory config), or refreshing the manifest after any edit under the factory templates so detector E pass

• house-voice

  Use when the agent's own replies run long, hedged or padded, or when the user wants to set a voice for them, such as "answer first", "stop restating my question", "no summary at the end", "shorter replies, no filler", or "make it stick for every session". It applies a short rules block to the agent'

• idea

  Use when the user has a raw idea, a "what if", or a problem hunch with no artifacts yet — the start of a product or feature run. Interviews the user and produces an idea brief (idea.md).

• implement-queue

  Use when a repo's backlog of ready GitHub issues, or of factory work orders, should be drained without the Owner answering each step — "work the queue", "drain the backlog", "implement the ready issues", "run the queue on a loop", a scheduled routine, or a direct invocation. Claims a batch of indepe

• implement

  Use when a breakdown exists and it's time to write code — working through work items test-first, checking them off as acceptance criteria are met — or when the user says to start building, start coding, or start working through the breakdown. The artifact is the code itself; progress lives in breakd

• knowledge-base

  Use when the ask is to set up, feed, or check a project knowledge base — "set up a knowledge base for this repo", "write down the gotchas an agent keeps tripping over", "capture what this PR taught us so the next session knows", "is our project knowledge stale". Keeps only non-inferable facts in doc

• launch-demo

  Use when a feature has shipped, or is about to, and the ask is a launch brief for it — "make the launch video", "write the launch copy for what we just shipped", "record a demo of this feature", "explain this release in plain words, with a clip". Produces two halves in one directory; plain copy (wha

• lean

  Use when the ask is for the least code that fully works, or for what can be cut — "simplest thing that works", "no new dependency", "no abstraction I don't need yet", "redo it with less code", "too many wrappers and layers, strip the code back", "is this over-engineered", "what can we delete", "revi

• next

  Use when the user wants to continue the pipeline, asks "what's next", or wants to start or resume a product, feature, or maintenance run without naming a stage. Reads artifact state and routes to the right stage skill.

• operate

  Use when shipped work has been in users' hands and it's time to capture feedback and run a retrospective — closing the loop into the next idea — or when the user asks how the release is landing or doing in production, or what we learned post-launch. Produces retro.md, completing the run.

• pipeline-board

  Generate the pipeline board — one self-contained theme-aware .svg placing every active run in the current repo on its current pipeline stage; swimlane rows per run, stage columns, done/current/ahead/skipped marks, Implement progress counts, in the family's light editorial style with a dark variant.

• polish

  Use when a user-facing interface is built, or being built, and should look and feel considered rather than generated — "this looks generic", "it looks AI-made", "critique this screen", "review the page itself, not the code — does it read well, does the layout hold", "polish the settings page before

• prd

  Use when an idea needs requirements — turning an idea brief into a PRD with scope and success criteria, or when the user asks for a PRD directly. Interviews the user and produces prd.md.

• prisma-migrations

  Use when a repo's Prisma schema change has to reach a database safely — "create a migration", "run prisma migrate", "deploy the database changes", "baseline the existing production database", "set up Prisma migrations in CI/CD", "a migration failed halfway in prod", "prisma says drift detected", "P3

• review

  Use when verified work needs a quality pass before shipping — examining the change for defects, design decay, and security issues — or when the user asks for a code review of the run's changes or says to give the change a quality check. Produces review.md. It is not for acting on reviewer comments l

• ship

  Use when reviewed work is ready to go to production — pre-flight checks, release steps, rollback plan — or when the user asks to ship, release, or deploy the work, get it into production, push it out to users, go live, or cut a release. Produces release.md.

• ux-design

  Use when a PRD declares a user-facing surface (ux required) and flows/screens need designing before technical work, or when the user asks for UX design directly. Interviews the user and produces ux.md.

• ux-patterns

  Use when a product's interface behaves differently from screen to screen and the ask is to define how it should behave, once, for the whole project — "make our UX consistent", "write down our UX patterns", "one screen confirms delete and another offers undo", "how should we handle loading, errors an

• ux-writing

  Use when the words in a product's interface need auditing, rewriting or writing — "audit our copy", "our error messages are useless", "make the microcopy consistent", "write the empty states", "what should this button say", "do we call it a workspace or a project", "set up a voice and tone guide", "

• verify

  Use when implementation is complete and it's time to demonstrate the work meets the PRD's success criteria — running tests and collecting evidence — or when the user asks to verify the work. Produces verification.md.