| name | findings-to-tickets |
| description | Convert lean-findings.json into a ready-to-import sprint backlog — GitHub Issues, Jira, or Linear tickets with severity labels, effort estimates, acceptance criteria, and pattern links. Use this skill whenever the user wants audit findings as tickets/issues/backlog items, asks to "make this actionable" or "put these in Jira/GitHub", or wants remediation work assigned to a sprint. Part of Lean Agentic AI Skills; a transformer from findings to work items. |
Findings to Tickets
Transformer skill — the actionability bridge. Input: one or more findings files, plus the target tracker (GitHub/Jira/Linear) and any team conventions (labels, components, estimate scale). Output: importable ticket definitions (JSON/CSV for the tracker's import, or gh/jira CLI commands, or direct creation when a tracker connector is available and the user confirms).
An audit that ends as a PDF decays; an audit that ends as a backlog gets burned down. The mapping is mechanical because the contract already carries everything a good ticket needs.
Ticket mapping
Per finding:
- Title — imperative rewrite of the finding title ("Serve hero images in modern formats" not "Hero images served as PNG").
- Body — issue + evidence verbatim (the evidence is what convinces the assignee it's real), the fix as the proposed approach, the pattern URL as reference, and a one-line "why it matters" from the impact field — directional language preserved, never embellished into savings claims.
- Acceptance criteria — derived from the fix, checkable ("images in the first viewport served as AVIF/WebP with srcset; verified in a network trace"). Where the finding pairs with a measurement, the criterion says measured-before/after, not "feels faster".
- Labels —
sustainability, severity (sev:high), SCI term (sci:E), producer skill (audit:web-carbon-audit).
- Estimate — from the effort field mapped to the team's scale (low→S/1pt etc.), flagged as a starting point for the team's own sizing.
- Grouping — quick wins (effort low, severity ≥ medium) batched into one clearly-labeled early milestone; structural items (effort high) as epics with the related findings as children when several share a cause.
Rules
- Fidelity over polish: tickets never claim more than the finding does; the
methodology caveats travel in the epic/milestone description so context survives the export.
passed items are not tickets. out_of_scope items become at most one "investigate" ticket each, clearly typed as investigation, and only when the user opts in.
- Dedup on re-export: stable finding
id goes in the ticket body as a marker (lean-id: hero-images-legacy-format) so re-running the export after a re-audit updates rather than duplicates — and closes the loop with findings-diff (resolved findings → suggested ticket closures, listed for human confirmation, never auto-closed).
- Direct tracker writes only with explicit confirmation and a dry-run list shown first.
Cost signal rendering
Include the cost signal. Where a finding carries cost_signal, include one line in the ticket body: "Cost driver: {driver} — currently {observed}. Direction: {direction}." This gives assignees the honest business case without inventing figures.
Not this skill's job
Producing findings (producers), deciding priorities beyond the severity/effort data (the team's call), gating merges (lean-regression-gate).