Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From playbooks-virtuoso
Drives a ticket from analysis through investigation, planning, TDD implementation, committing, and PR creation. Adapts to your stack via an interactive supplement on first run.
npx claudepluginhub krzysztofsurdy/code-virtuoso --plugin agents-virtuosoHow this skill is triggered — by the user, by Claude, or both
Slash command
/playbooks-virtuoso:ticket-delivery <ticket-id><ticket-id>The summary Claude sees in its skill listing — used to decide when to auto-load this skill
End-to-end workflow that takes a ticket ID and drives it through analysis, codebase investigation, planning, TDD implementation, committing, and PR creation. Adapts to your stack via an interactive supplement created on first run.
Fetches next ready_to_develop ticket via Board API or Supabase, creates feature/fix/chore branch, implements autonomously through build, code review, QA, docs checks, and ships without stopping.
Generates structured GitHub issues with TDD plans, acceptance criteria, and agent instructions for autonomous PR lifecycle management.
Share bugs, ideas, or general feedback.
End-to-end workflow that takes a ticket ID and drives it through analysis, codebase investigation, planning, TDD implementation, committing, and PR creation. Adapts to your stack via an interactive supplement created on first run.
Before anything else, check for a supplement file stored alongside this skill (e.g., .supplement.md in the skill directory).
Read the file and load all $VARIABLE values for use throughout the workflow.
Run an interactive setup. Present an interactive prompt (or the platform's equivalent) for each question, wait for the answer, then proceed to the next. Save all answers to a supplement file stored alongside this skill (e.g., .supplement.md in the skill directory).
Questions to ask (see supplement reference for full details):
gh, glab)? Main branch name?SKIP=lint,test git commit)After saving, confirm: "Supplement saved. You can edit it anytime at the supplement file path or delete it to re-run setup."
This workflow can use a multi-agent team when available. The coordinating agent delegates to specialized sub-agents for parallel investigation.
| Strategy | Purpose |
|---|---|
| Coordinating agent | Orchestrates the full workflow, delegates investigation, reviews results |
| Investigation sub-agents (x1-3) | Explore specific codebase layers in parallel during Phase 3 |
| Implementation sub-agent | Executes TDD cycles during Phase 6 (or the coordinating agent does this directly) |
Delegate to specialized sub-agents if available. Use delegation only when the ticket scope justifies parallel investigation. For small bug fixes, a single agent can handle everything alone.
If $TICKET_MCP_TOOL is configured:
Use $TICKET_MCP_TOOL to fetch ticket $TICKET_ID
If no integration tool is configured: Ask the developer: "Please paste the ticket title, description, and acceptance criteria."
Extract and organize:
If $ERROR_TRACKING_MCP_TOOL is configured and ticket is a bug:
Use $ERROR_TRACKING_MCP_TOOL to fetch error details linked in the ticket
Extract: stack trace, affected file paths, frequency, first/last seen.
If no integration tool is configured: Ask developer to paste relevant error details or stack traces.
If $LOGGING_TOOL is configured:
Fetch relevant log entries around the error timeframe.
If manual: Ask developer to paste relevant log snippets if available.
Present a structured summary:
TICKET: $TICKET_ID
TYPE: [bug|feature|improvement|refactor]
SUMMARY: [one-line summary]
ACCEPTANCE CRITERIA: [numbered list]
ERROR CONTEXT: [if bug - stack trace summary, affected files]
INITIAL HYPOTHESES: [2-3 possible approaches]
Ask the developer: "Does this look correct? Any additional context before I investigate the codebase?"
git fetch origin
git checkout $MAIN_BRANCH
git pull origin $MAIN_BRANCH
Do NOT create a feature branch yet - that happens in Phase 5 after planning.
Investigate the codebase to understand the area affected by the ticket. Adapt the investigation to your project's architecture ($ARCHITECTURE).
Run these in parallel when using sub-agents, or sequentially as a single agent:
$ORM): check mappings, migrations, schema$DB_QUERY_COMMAND): verify current data state if relevantAfter all areas are explored, compile:
AFFECTED FILES: [list of files that will likely need changes]
DEPENDENCIES: [services, classes, interfaces involved]
EXISTING TESTS: [test files covering the affected area]
DATABASE IMPACT: [schema changes needed, if any]
API IMPACT: [endpoint changes, if any]
RISK AREAS: [parts of the codebase that could break]
Create a detailed plan before writing any code.
## Implementation Plan for $TICKET_ID
### Changes Required
1. [File path] - [What changes and why]
2. [File path] - [What changes and why]
...
### New Files
1. [File path] - [Purpose]
...
### Test Plan
1. [Test file] - [What to test]
2. [Test file] - [What to test]
...
### Migration / Schema Changes
[If applicable]
### Order of Operations
1. [First step - typically write failing tests]
2. [Second step]
...
If the implementation involves design decisions, consider consulting specialized skills:
| Situation | Recommended Skill |
|---|---|
| Design patterns needed | design-patterns |
| Code smells / refactoring | refactoring |
| SOLID principles | solid |
| PR message writing | pr-message-writer |
| Work summary report | report-writer |
Present the plan to the developer and wait for approval before proceeding. "Here is my implementation plan. Shall I proceed, or would you like changes?"
After plan approval, create the feature branch.
Using $BRANCH_PATTERN from supplement:
git checkout -b $BRANCH_PATTERN
Example patterns:
feat/PROJ-123-short-descriptionfix/PROJ-123-short-descriptionPROJ-123/short-descriptionFollow a strict TDD cycle. Use $TEST_COMMAND from supplement.
For each item in the test plan:
$TEST_COMMAND path/to/TestFileWrite the minimum code to make each test pass:
$TEST_COMMAND path/to/TestFileAfter tests pass:
Run the broader test suite to catch regressions:
$TEST_COMMAND [relevant test directory or suite]
Fix any failures before proceeding.
Commit using the project's conventions ($COMMIT_FORMAT):
$SKIP_HOOKS git add [specific files]
git commit -m "$COMMIT_FORMAT"
For large changes, make multiple focused commits rather than one monolithic commit.
After all changes are committed, generate a summary:
## Implementation Summary for $TICKET_ID
### Changes Made
- [File]: [What changed and why]
- [File]: [What changed and why]
### Tests Added/Modified
- [Test file]: [What is tested]
### Commits
- [hash]: [message]
### Verification
- All new tests pass: YES/NO
- Existing tests pass: YES/NO
- Schema changes applied: YES/NO/N/A
### Notes
- [Any caveats, follow-up work, or decisions made during implementation]
Use the pr-message-writer skill if available, or create the PR directly.
Invoke the skill with the implementation summary and ticket context to generate a well-structured PR description.
Use $VCS_CLI (e.g., gh, glab) to create the PR:
git push -u origin HEAD
$VCS_CLI pr create --title "$TICKET_ID: [short description]" --body "[PR body]"
The PR body should include:
If the report-writer skill is available, invoke it to create a work summary report covering:
This is optional but recommended for complex tickets.
Never skip Phase 0. The supplement ensures the workflow adapts to your stack. Without it, the skill cannot function correctly.
Always get plan approval before coding. Phase 4 must end with explicit developer approval.
TDD is not optional. Write tests first. If the project has no test infrastructure, flag this to the developer and discuss before proceeding.
Commit granularity matters. One logical change per commit. Do not bundle unrelated changes.
Never force-push to the main branch. Always work on feature branches.
Ask when uncertain. If the ticket is ambiguous, ask the developer rather than guessing. Wrong assumptions waste more time than a quick question.
Respect existing patterns. Match the project's coding style, naming conventions, and architectural patterns - even if you would do it differently.
Keep the developer informed. At the end of each phase, provide a brief status update. Do not silently proceed through multiple phases.
Handle failures gracefully. If tests fail unexpectedly, if the codebase does not match expectations, or if the ticket requirements are unclear - stop and communicate rather than pushing through.
Security first. Never commit secrets, credentials, or sensitive data. If a ticket requires configuration changes, use environment variables or configuration files that are in .gitignore.
| Reference | Contents |
|---|---|
| supplement-questions | Full details on each supplement question, options, follow-ups, and example entries |
| Situation | Recommended Skill |
|---|---|
| Design patterns needed during planning | design-patterns |
| Code smells discovered during investigation | refactoring |
| SOLID violations found during review | solid |
| Writing the PR description | pr-message-writer |
| Generating a work summary report | report-writer |