Sprint security review

Skill timwukp/agent-skills-best-practice/skills/skills/sprint-security-review

35 portable agent skills (Agent Skills spec) for Kiro & Claude Code: Scrum DevSecOps roles, PCI-DSS/MAS TRM compliance, AWS Well-Architected reviews — each with evals and a 4-layer tested methodology

Install

npx -y skills add timwukp/agent-skills-best-practice --skill sprint-security-review

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

7 stars7 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

Prepares sprint review and retrospective materials that demonstrate security alongside features: green build reports aggregating SAST/DAST/dependency scan results, completed security story summaries, and security metrics trends. Triggers on: "prepare sprint review", "green build report", "security metrics for this sprint", "demo our security work", "sprint security summary", "retro on our pipeline".

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.5 KB, as published. Nobody here has run it

Sprint Security Review

Make security work visible in the sprint review instead of invisible plumbing. Produce a report that lets the team demo security outcomes to stakeholders in 5 minutes, plus metrics that show trend, not just snapshot.

What to Gather

Ask for (or extract from CI/scan outputs the user provides):

Pipeline results for the sprint's final build: SAST, DAST, dependency/container scans, test results and coverage.
Security stories completed this sprint (IDs and one-line outcomes).
Open security debt: counts by severity, and anything that aged past SLA.
Two or three sprint-over-sprint metrics — pick from: mean time to remediate by severity, new findings vs. resolved, false-positive rate, security debt trend, coverage trend.

If the user can't supply real numbers, generate the template with placeholders and mark them clearly — never invent metrics.

Green Build Report Template

# Sprint [N] — Green Build Report

## Pipeline Status
| Stage | Status | Details |
|-------|--------|---------|
| SAST | ✅/❌ | [new High/Critical count; accepted Medium count with link to acceptance] |
| DAST | ✅/❌ | [findings against staging] |
| Dependency scan | ✅/❌ | [Critical CVEs; notable upgrades] |
| Container/image scan | ✅/❌ | [base image currency] |
| Unit tests | ✅/❌ | [pass count, coverage %] |
| Integration tests | ✅/❌ | [pass count] |

## Security Stories Completed
- [ID] [Title] — [one-line demonstrable outcome, e.g. "transfer API now rejects malformed amounts; demo: curl with attack payload returns 422"]

## Security Debt Position
- Open: [n Critical / n High / n Medium / n Low] ([↑/↓ vs last sprint])
- Past SLA: [items, owner, plan]

## Metrics
- [Metric]: [value] ([trend vs previous sprint])

## Risks & Asks
- [Anything needing stakeholder decision: risk acceptance, capacity, tooling]

Demo Guidance

For each completed security story, propose a 30-second demonstration that shows the control working — the blocked attack, the alert firing, the audit log entry — rather than describing code. Stakeholders remember "we watched the brute-force attempt get locked out", not "we improved auth".

Retrospective Prompts (security angle)

Offer these when the team runs the retro:

Which security findings could have been caught earlier in the pipeline, and what gate would have caught them?
Did security stories get squeezed out mid-sprint? If so, was the capacity reserve real?
Any false-positive pain worth tuning rules for?
Did anything ship with accepted risk — and is that acceptance documented?

Guidelines

A red pipeline stage is not shameful in the report — hiding it is. Show the failure, the cause, and the plan; that builds more stakeholder trust than a suspiciously green wall.
Keep the whole report to one page; link out to scan dashboards for detail.
Trends beat snapshots: always compare against at least the previous sprint where data exists.