Skills publicadas
Mostrando 12 de 27qa
Side-route skill and single entry point for bug conversations. Use when the user is reporting observed failures and wants durable GitHub issues filed in project language. Delegates per-issue to /triage-issue for bugs that need root-cause diagnosis, then returns to the loop. Not for already-scoped implementation work (use /execute).
design-an-interface
Invoked helper skill for unresolved module boundaries, usually called from /write-a-prd. Use to compare multiple interface shapes for a module or component when caller ergonomics and surface area are still unclear. Not for API contract review or already-settled designs.
api-design-review
Invoked helper skill for higher-risk API contract decisions, usually called from /research or /write-a-prd. Use when the unresolved question is API shape, compatibility, auth, webhook design, or paradigm choice. Not a default top-level workflow step or a substitute for ordinary implementation work.
walk-commits
Side-route skill for an interactive, commit-by-commit comprehension walkthrough of a finished branch before merge. Use when the person about to merge didn't author the diff — or hasn't internalized it — and needs to understand each commit's intent, riskiest line, deliberate oddities, and what's absent by design, with per-commit sign-off. Not a defect finder (that's /pre-merge), not a behavioral ch
prototype
Build a throwaway prototype to flush out a question before committing to it. Routes between three branches — a runnable terminal app for state/business-logic questions (LOGIC), several radically different UI variations toggleable from one route (UI), or a focused spike that gives a binary verdict on whether a technical assumption holds (FEASIBILITY). Use when the user wants to prototype, sanity-ch
improve-codebase-architecture
Side-route skill for architecture exploration and deepening opportunities. Use when the user wants to find structural improvements, shallow-module pain, or refactor opportunities that may flow into /request-refactor-plan or /execute. Not for already-scoped implementation tasks.
help
Side-route orientation skill. Use when the user asks 'what's next', 'where am I', or is returning to a repo mid-pipeline and wants to know which skill to run next. Reads repo state (branch, PRs, issues, research archive, milestones) and recommends one next step with a one-line reason. Not for executing work — only for routing.
request-refactor-plan
Side-route skill for planning refactors as safe, tiny-commit RFCs. Use when the user wants a structured refactor plan before implementation. Feeds approved refactor work back into /execute. Not for new-feature shaping or already-concrete implementation tasks.
create-milestone
Primary planning branch after /shape for major-tranche work that requires multiple independent PRDs. Use to create a GitHub milestone plus sequenced feature issues that will later mature from roadmap bet to research-ready to prd. Not for single-feature shaping, single-PRD big-batch work (which gets a container milestone from /write-a-prd), decomposition of a finished PRD, or implementation-ready w
correct-course
Side-route skill for explicit backtracking when an upstream artifact becomes untrustworthy. Use when research, PRD, or slice decomposition has been invalidated by new information and you need to clean up stale artifacts before re-running an earlier pipeline step. Not for forward progress, fresh shaping, or routine bug fixes.
execute
Primary pipeline execution step after /prd-to-issues or for clearly scoped implementation work. Use to build, verify, and commit a concrete slice, delegating to /tdd for backend work and behavior-heavy frontend logic when red-green-refactor will reduce risk. Not for shaping or pre-merge review.
shape
Primary pipeline entry for structured requirements discovery. Use first when the problem, scope, or user needs are still fuzzy and you need shared understanding before /research. Not for already-shaped PRDs or implementation-ready work.