Menú
Start working on a ticket, dev workflow, work on an issue, pick up a ticket
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | dev-workflow |
| description | Start working on a ticket, dev workflow, work on an issue, pick up a ticket |
| disable-model-invocation | false |
| argument-hint | [issue-number-or-description] |
Run the full developer workflow end-to-end: pick a ticket, branch, plan, implement, commit, simplify, PR, wait for CI, and address feedback. Execute each step sequentially, waiting for completion before moving to the next.
Ticket selection:
$ARGUMENTS is provided, treat it as an issue number or description.gh issue list --assignee @me --limit 10 to show issues assigned to the user.gh issue list --limit 10.Ticket creation (if no existing ticket matches):
/tmp/issue-draft.md).gh issue create with the approved values.Branch creation: Invoke the cut-branch skill with the issue number.
Planning: Invoke EnterPlanMode (the built-in /plan command). Present a plan for implementing the ticket. Wait for the user to approve the plan before continuing.
Implementation: Execute the approved plan. Build the feature or fix step-by-step.
Visual/functional verification (conditional): If the implementation touched UI components, styles, layouts, or templates, spawn a Playwright subagent to verify the feature works as intended. The agent should use its best judgment on verification method (screenshots, checking DOM elements, verifying text content, testing interactions, etc.). If verification passes, proceed without waiting for approval. If it fails, fix the issue before continuing.
Initial commit: Invoke the commit-commands:commit skill.
Simplify: Only after step 7's commit has completed, invoke the simplify-agent skill on the changed code. Do not run commit and simplify in parallel or batch them in one tool turn — the commit must be on disk before simplify reads the tree, and simplify's edits must land as a separate follow-up commit. This step is for pre-PR cleanup — refactoring to cleaner code, removing duplication, improving reuse. It is NOT for addressing PR review feedback (that's step 11). The simplify-agent skill launches code-simplifier agents that review for reuse, quality, and efficiency issues, then fix what they find.
Push & PR: Invoke the commit-commands:commit-push-pr skill.
Wait for CI: Spawn a background agent that watches gh pr checks until all checks complete, then reports pass/fail. Continue to the next step only after the background agent completes.
Address feedback: Invoke the address-pr-feedback skill with the PR number. This handles automated review bot feedback and human reviewer comments — different from the simplify step which is a pre-PR self-review.
Final review: Ask the user if they have further feedback on the PR. If so, address it. If not, the workflow is complete.
Run the same comprehensive review your CI runs on PRs, but locally against your full local-vs-remote diff and printed as text in the session, with an optional fix loop. Use when the user wants to mirror or preview the CI code review before pushing, get their branch CI-clean, or run an iterative review-then-fix loop. Triggers on "run the CI review locally", "preview the CI review", "mirror CI", "ci review", "will CI pass", "review-and-fix before pushing". For a plain read-only local review with no CI-parity framing or fix loop, prefer /review-local instead.
For coding/implementation tasks, use your own judgement to delegate the actual code-writing to a subagent running an appropriately lower-power model, to conserve top-tier tokens. Triggers whenever a task is primarily writing or editing code (features, fixes, refactors, mechanical edits). Skip for judgement-heavy work (design, debugging, auditing, synthesis).
Merge the current PR with branch deletion, but only after CI passes. Use when the user clearly means "merge the open PR" (e.g. plain "merge", "merge it", "ship it"). Do NOT use for git branch merges ("merge main into X") or code merges.
Inspect Claude Code session logs (transcripts) for the current or another project. Use when the user explicitly asks to "look at the claude logs", "parse my session", "what did I ask claude", "show the transcript", "list claude sessions", or similar phrasings referencing Claude's own JSONL logs.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Docs-aware grilling. Explores the repo's existing docs first, then interviews the user relentlessly about a plan or design while cross-referencing those docs and the code. Use when user wants to stress-test a plan against the project's existing documentation, says "grill me with docs", "grill against the docs", or similar.