Ticket scoping
WHEN turning a finding, RCA, PR comment, or rough idea into trackable work. Triggers: 'file an issue', 'break this epic down', 'scope this work', 'sharpen this ticket', 'turn this finding into a ticket', 'what should the AC be?'. OUTPUT: paste-ready issue(s) for Linear/Jira/GitHub (title, problem, approach, AC checklist, size). PAIR AFTER: decision-review (file the chosen path). NOT FOR: writing an update on existing tickets (use status-update).From its SKILL.md
npx -y skills add arniesaha/ctxops --skill ticket-scopingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.1 KB, 399 tokens by cl100k_base, as published. Nobody here has run it
ticket-scoping
Use when turning intent into trackable work artifacts. Different from status-update (reports on existing work).
Workflow
- Restate the outcome in one sentence. If the user gave a solution, recover the problem behind it.
- Decide the shape:
- single issue
- epic + 2-5 children
- spike (time-boxed investigation) before any of the above
- For each issue, draft:
- title (verb-led, concrete)
- problem and observed evidence (link to memory / logs / dashboards)
- proposed approach (one paragraph, not a design doc)
- acceptance criteria (testable, not aspirational)
- out of scope
- dependencies / blockers
- rough size: XS / S / M / L (L means break it up)
- If filing into an existing project, look up the parent epic, label conventions, and any related issues before writing.
- End with a one-line summary the user can paste into a tracker.
Output Shape
Per issue:
- Title
- Problem
- Approach
- Acceptance criteria (checklist)
- Out of scope
- Dependencies
- Size
- Suggested parent / labels
For epics, add: child list with order and which can run in parallel.
Rules
- Acceptance criteria must be checkable from artifact, log, or dashboard. No "improved UX" without a measurable signal.
- A child issue that has no AC is a spike. Mark it that way.
- Do not invent issue keys or PR numbers. If a parent epic is unknown, leave a placeholder.
- Sizing is a call, not a vote. State the assumption that drives the size.
- If the work is reversible and small, prefer one issue. Do not over-decompose.
- Flag anything that needs cross-team buy-in before it can start.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most requirements skills give in 399 tokens
Counted across 129 of the 157 authors here whose files we hold, read 2026-09-06
- Ask one question at a timein 7 of 129
- Provide testable acceptance criteriain 5 of 129, across 3 files
- Place stakeholders in the power-interest gridin 5 of 129, across 4 files
- Clarify goals, constraints, and required inputsin 4 of 129
- Provide actionable steps and verificationin 4 of 129
- Use AskUserQuestions for structured elicitationin 4 of 129, across 2 files
- Ask for clarification on ambiguous requirementsin 4 of 129, across 2 files
- Use open-ended questions only when choices cannot be predeterminedin 4 of 129, across 2 files
- Classify each stakeholder by power and interestin 4 of 129, across 3 files
- Conduct a thorough interview before writing the specin 4 of 129, across 2 files
- Write all functional requirements in EARS formatin 4 of 129, across 2 files
- Include non-functional requirements for performance and securityin 4 of 129, across 2 files
Said here and by no other author read
- restate the outcome in one sentence
- recover the problem behind a given solution
- choose single issue, epic, or spike
- draft title, problem, approach, criteria, and size
- keep the approach to one paragraph
- look up parent epic and labels before filing
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.