Install
$ agentstack add skill-kazdenc-builder-skills-retro ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Run a retrospective that produces action items, not just observations. A retro without specific next steps is a venting session.
Principles — hold these throughout:
- Blame-free. Focus on systems, processes, and circumstances — not people. "The deploy process let a bug through" not "Bob broke prod."
- Actions over observations. Every theme must produce a concrete change. If it doesn't lead to action, note it and move on.
- Max 3 action items. More than three won't get done. Prioritize ruthlessly.
Step 1: Set Context
Establish the boundaries before gathering input:
| Question | Answer | |----------|--------| | What period/project? | Name it specifically — "Sprint 14" or "Billing v2 launch" | | What was the goal? | What were we trying to accomplish? | | What actually happened? | State the outcome factually — shipped on time, missed by 2 weeks, hit metrics, didn't | | Who was involved? | List the team so contributions are visible | | Timeline | Start date, end date, key milestones |
Write a 2-3 sentence summary: "We set out to [goal]. We [what happened]. The result was [outcome]."
If the user hasn't provided this context, ask for it. Don't fabricate project history.
Step 2: Gather Input — The 4Ls
Use the 4Ls framework to collect observations. Ask the user to contribute to each category:
| Category | Prompt | What goes here | |----------|--------|----------------| | Liked | What went well? What should we keep doing? | Practices, decisions, or moments that worked | | Learned | What did we discover? What surprised us? | New knowledge, skills, or insights gained | | Lacked | What was missing? What held us back? | Resources, information, tools, or processes we needed but didn't have | | Longed For | What do we wish we had? What would make next time better? | Improvements, tools, practices, or changes we want |
Gathering tips:
- Ask for specifics, not generalities. "Liked: good communication" is useless. "Liked: daily 10-min standups kept everyone unblocked" is actionable.
- Aim for 3-5 items per category.
- If working async, give people a template to fill in before the session.
Step 3: Identify Themes
Group related items across the 4Ls. Look for patterns:
- Cluster related items. If three people mention deployment issues, that's a theme.
- Name each theme clearly. "Deployment reliability" not "various issues."
- Find root causes. For the biggest themes, use the 5 Whys:
Problem: Feature launched 2 weeks late.
Why? → Integration testing took longer than expected.
Why? → We discovered API incompatibilities late.
Why? → No integration test environment existed.
Why? → We hadn't invested in test infrastructure for this service.
Why? → Test infra wasn't prioritized because the team was focused on feature work.
Root cause: No dedicated time for test infrastructure investment.
Stop when you reach something the team can actually change. Don't go deeper than useful.
- Rank themes by impact. Which ones, if fixed, would make the biggest difference next time?
Step 4: Generate Action Items
For each of the top 2-3 themes, create one action item. Every action must be:
| Requirement | Example | |-------------|---------| | Specific | "Set up staging environment with seed data" — not "improve testing" | | Assigned | One owner, by name or role. "The team" owns nothing. | | Time-bound | "Complete by end of Sprint 15" — not "soon" |
ACTION ITEM TEMPLATE:
Theme: [theme name]
Action: [specific thing to do]
Owner: [person or role]
Due: [date or sprint]
Success looks like: [how we know it's done]
Hard limit: 3 action items. If you have 5 good ones, pick the 3 with highest impact. Carry the rest to next retro if they're still relevant.
Step 5: Write the Retro Summary
Produce a single document the team can reference:
# Retro: [Project/Sprint Name]
**Period:** [start] — [end]
**Team:** [names/roles]
**Goal:** [what we set out to do]
**Outcome:** [what actually happened]
## Summary
[2-3 sentences: goal, what happened, result]
## 4Ls
### Liked
- [item]
- [item]
### Learned
- [item]
- [item]
### Lacked
- [item]
- [item]
### Longed For
- [item]
- [item]
## Themes
1. **[Theme name]** — [1-sentence description]. Root cause: [root cause].
2. **[Theme name]** — [1-sentence description]. Root cause: [root cause].
3. **[Theme name]** — [1-sentence description]. Root cause: [root cause].
## Action Items
| # | Action | Owner | Due | Done? |
|---|--------|-------|-----|-------|
| 1 | [specific action] | [owner] | [date] | [ ] |
| 2 | [specific action] | [owner] | [date] | [ ] |
| 3 | [specific action] | [owner] | [date] | [ ] |
## Notes
[Anything else worth recording that doesn't fit above]
Output
Deliver the retro summary using the template above. Customize it to the actual project — don't leave placeholder text. If information is missing, flag what you need from the user rather than filling in generic content.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: kazdenc
- Source: kazdenc/builder-skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.