ticket-writer

Name: ticket-writer
Author: krzysztofsurdy

25installs1forks

How to install ticket-writer?

krzysztofsurdy/code-virtuoso/ticket-writer

$npx -y skills add krzysztofsurdy/code-virtuoso --skill ticket-writer

Installs into the current project.

Summary

Interactive tool to write high-quality tickets of the right type - story, subtask, issue, bug, epic, or initiative - each with its own structure, required fields, and quality checks. Use when the user asks to write a ticket, draft a user story, file a bug report, scope an epic, d

Files · 1

View on GitHub

SKILL.md

1	# Ticket Writer
2
3	Pick the right ticket type, then fill in only the fields that type demands. A story is not a bug; an epic is not an initiative. Each type has a distinct audience, scope, and definition of done - mixing them produces vague, unactionable tickets that bloat backlogs.
4
5	## Core Principles
6
7	\| Principle \| Meaning \|
8	\|---\|---\|
9	\| Type drives structure \| The type decides the required fields - never use a single template for everything \|
10	\| Outcomes over outputs \| Describe the change the work creates, not the activity performed \|
11	\| Small enough to finish \| Stories and subtasks fit a sprint; epics fit a quarter; initiatives span multiple quarters \|
12	\| Testable acceptance \| Every story, subtask, and bug has acceptance criteria that a reviewer can verify \|
13	\| Context, not prose \| Prefer tables, lists, and labelled sections over paragraphs - readers skim \|
14	\| One ask per ticket \| If a ticket has two unrelated goals, split it \|
15
16	---
17
18	## Type Hierarchy and Selection
19
20	Tickets form a hierarchy. Pick the highest level where the work still has a single, coherent purpose.
21
22	```
23	Initiative (multi-quarter strategic outcome)
24	Epic (quarter-scale goal, one product area)
25	Story (sprint-scale user-visible value)
26	Subtask (implementation slice of a story)
27	Bug (defect against current behaviour)
28	Issue (anything else - chore, spike, question)
29	```
30
31	### When to Use Each Type
32
33	\| Type \| Audience \| Scope \| Typical Duration \| Key Question \|
34	\|---\|---\|---\|---\|---\|
35	\| Initiative \| Execs, product leadership \| Cross-team strategic goal \| 1-4 quarters \| What outcome do we want for the business or users? \|
36	\| Epic \| Product, engineering, design \| Single product area, multiple stories \| 1 quarter \| What capability or experience are we delivering? \|
37	\| Story \| Dev team, QA, PM \| One user-facing change \| Fits in a sprint \| As a [user], what can I now do? \|
38	\| Subtask \| One developer \| Technical slice of a story \| Hours to 1-2 days \| What specific implementation step does this cover? \|
39	\| Bug \| Dev team, QA \| A deviation from intended behaviour \| Fix-sized \| What is broken, and how do I reproduce it? \|
40	\| Issue \| Dev team \| Chore, spike, question, tech debt, docs \| Variable \| What needs attention that isn't user-facing work? \|
41
42	### Type Decision Tree
43
44	1. Is this a deviation from intended behaviour? -> Bug
45	2. Is this a strategic goal spanning multiple teams or quarters? -> Initiative
46	3. Is this a large body of work that needs to be broken down but belongs to one product area? -> Epic
47	4. Is this user-visible value that fits in a sprint? -> Story
48	5. Is this an implementation slice of an existing story? -> Subtask
49	6. None of the above (chore, spike, investigation, tech debt, question)? -> Issue
50
51	---
52
53	## Workflow
54
55	### Phase 1: Type Selection
56
57	If the user provided a type as an argument, use it. Otherwise present a selectable menu (use `AskUserQuestion` or the platform's equivalent interactive prompt) listing the six types with their one-line descriptions from the table above. Never dump the full table as plain text - keep the menu compact.
58
59	If the user's intent is clear from context (e.g., they said "write a bug report" or "create an epic for checkout redesign"), skip the menu and confirm the inferred type with a single yes/no prompt.
60
61	### Phase 2: Load the Type-Specific Reference
62
63	Read the matching reference file for the selected type:
64
65	\| Type \| Reference \|
66	\|---\|---\|
67	\| Story \| [references/story.md](references/story.md) \|
68	\| Subtask \| [references/subtask.md](references/subtask.md) \|
69	\| Issue \| [references/issue.md](references/issue.md) \|
70	\| Bug \| [references/bug.md](references/bug.md) \|
71	\| Epic \| [references/epic.md](references/epic.md) \|
72	\| Initiative \| [references/initiative.md](references/initiative.md) \|
73
74	Each reference contains:
75	- The required fields
76	- The optional fields
77	- A field-by-field questionnaire (questions, options, follow-ups)
78	- The output template
79	- Quality checks specific to that type
80
81	### Phase 3: Run the Questionnaire
82
83	Ask only the questions the reference lists for the selected type. Follow these rules:
84
85	1. Batch compatible questions (3-4 per prompt) when using an interactive menu tool. Use free-text prompts only when the answer is genui

People who liked this also viewed

6 picks

Type

ticket-writer

25installs1forks

View on GitHub

How to install ticket-writer?

krzysztofsurdy/code-virtuoso/ticket-writer

$npx -y skills add krzysztofsurdy/code-virtuoso --skill ticket-writer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Ticket Writer
2
3	Pick the right ticket type, then fill in only the fields that type demands. A story is not a bug; an epic is not an initiative. Each type has a distinct audience, scope, and definition of done - mixing them produces vague, unactionable tickets that bloat backlogs.
4
5	## Core Principles
6
7	\| Principle \| Meaning \|
8	\|---\|---\|
9	\| Type drives structure \| The type decides the required fields - never use a single template for everything \|
10	\| Outcomes over outputs \| Describe the change the work creates, not the activity performed \|
11	\| Small enough to finish \| Stories and subtasks fit a sprint; epics fit a quarter; initiatives span multiple quarters \|
12	\| Testable acceptance \| Every story, subtask, and bug has acceptance criteria that a reviewer can verify \|
13	\| Context, not prose \| Prefer tables, lists, and labelled sections over paragraphs - readers skim \|
14	\| One ask per ticket \| If a ticket has two unrelated goals, split it \|
15
16	---
17
18	## Type Hierarchy and Selection
19
20	Tickets form a hierarchy. Pick the highest level where the work still has a single, coherent purpose.
21
22	```
23	Initiative (multi-quarter strategic outcome)
24	Epic (quarter-scale goal, one product area)
25	Story (sprint-scale user-visible value)
26	Subtask (implementation slice of a story)
27	Bug (defect against current behaviour)
28	Issue (anything else - chore, spike, question)
29	```
30
31	### When to Use Each Type
32
33	\| Type \| Audience \| Scope \| Typical Duration \| Key Question \|
34	\|---\|---\|---\|---\|---\|
35	\| Initiative \| Execs, product leadership \| Cross-team strategic goal \| 1-4 quarters \| What outcome do we want for the business or users? \|
36	\| Epic \| Product, engineering, design \| Single product area, multiple stories \| 1 quarter \| What capability or experience are we delivering? \|
37	\| Story \| Dev team, QA, PM \| One user-facing change \| Fits in a sprint \| As a [user], what can I now do? \|
38	\| Subtask \| One developer \| Technical slice of a story \| Hours to 1-2 days \| What specific implementation step does this cover? \|
39	\| Bug \| Dev team, QA \| A deviation from intended behaviour \| Fix-sized \| What is broken, and how do I reproduce it? \|
40	\| Issue \| Dev team \| Chore, spike, question, tech debt, docs \| Variable \| What needs attention that isn't user-facing work? \|
41
42	### Type Decision Tree
43
44	1. Is this a deviation from intended behaviour? -> Bug
45	2. Is this a strategic goal spanning multiple teams or quarters? -> Initiative
46	3. Is this a large body of work that needs to be broken down but belongs to one product area? -> Epic
47	4. Is this user-visible value that fits in a sprint? -> Story
48	5. Is this an implementation slice of an existing story? -> Subtask
49	6. None of the above (chore, spike, investigation, tech debt, question)? -> Issue
50
51	---
52
53	## Workflow
54
55	### Phase 1: Type Selection
56
57	If the user provided a type as an argument, use it. Otherwise present a selectable menu (use `AskUserQuestion` or the platform's equivalent interactive prompt) listing the six types with their one-line descriptions from the table above. Never dump the full table as plain text - keep the menu compact.
58
59	If the user's intent is clear from context (e.g., they said "write a bug report" or "create an epic for checkout redesign"), skip the menu and confirm the inferred type with a single yes/no prompt.
60
61	### Phase 2: Load the Type-Specific Reference
62
63	Read the matching reference file for the selected type:
64
65	\| Type \| Reference \|
66	\|---\|---\|
67	\| Story \| [references/story.md](references/story.md) \|
68	\| Subtask \| [references/subtask.md](references/subtask.md) \|
69	\| Issue \| [references/issue.md](references/issue.md) \|
70	\| Bug \| [references/bug.md](references/bug.md) \|
71	\| Epic \| [references/epic.md](references/epic.md) \|
72	\| Initiative \| [references/initiative.md](references/initiative.md) \|
73
74	Each reference contains:
75	- The required fields
76	- The optional fields
77	- A field-by-field questionnaire (questions, options, follow-ups)
78	- The output template
79	- Quality checks specific to that type
80
81	### Phase 3: Run the Questionnaire
82
83	Ask only the questions the reference lists for the selected type. Follow these rules:
84
85	1. Batch compatible questions (3-4 per prompt) when using an interactive menu tool. Use free-text prompts only when the answer is genui

People who liked this also viewed

6 picks

Type