Ticket scoping

Skill arniesaha/ctxops/skills/ticket-scoping

Agent skills (open standard) for the bookends of the agent loop: context assembly, decision review, and work-shaping outputs. Works with Claude Code and any Agent Skills harness. Ships its own adoption and value measurement.

Install

npx -y skills add arniesaha/ctxops --skill ticket-scoping

Assembled 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.

What its author says it does

Copied from the file, not written here

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).

SKILL.md

2.1 KB, 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.