retro
by garrytanretro is a project retrospective skill for engineering teams. It analyzes commit history, work patterns, and prior learnings to generate a structured weekly retro with continuity. Use retro for sprint reviews, what did we ship questions, and Project Management check-ins.
This skill scores 66/100, which means it is listable but best presented with caution. It has a clearly named weekly retrospective workflow, explicit triggers, and substantial operational content, so directory users can likely install it and know when to use it. However, the file also shows placeholder markers and no companion scripts, references, or install command, which reduces confidence in fast adoption and low-guesswork execution.
- Clear use case and triggers: "weekly retro," "what did we ship," and "engineering retrospective" are explicitly defined in the frontmatter.
- Strong operational depth: the body is large and includes many headings, code fences, and repo/file references, suggesting a real workflow rather than a stub.
- Persistent context support via gbrain queries for prior retros, recent timeline events, and recent learnings adds agent leverage.
- Placeholder markers such as todo, wip, and placeholder appear in the repository signals, which weakens trust in polish and completeness.
- No install command and no support files (scripts, references, resources, or rules) are present, so setup and reuse may require more manual inference.
Overview of retro skill
What retro is for
retro is a project retrospective skill for engineering teams. It turns commit history, recent timeline data, and prior learnings into a weekly retro that answers “what did we ship?” and “what changed in the last sprint?” If you need a retro skill that produces a structured team review instead of a generic status summary, this is the fit.
Who should install it
Use retro if you want a repeatable retro guide for weekly engineering reviews, sprint endings, or manager check-ins. It is especially useful for Project Management workflows where you need concise progress framing, per-person contribution signals, and trend awareness across weeks.
What makes it different
The skill is built around persistent memory, not a one-off prompt. It reads prior retros, recent timeline events, and recent learnings so each run has continuity. That makes it more useful when you care about momentum, carryover issues, and whether the team is actually improving over time.
How to Use retro skill
Install and trigger it
Install with:
npx skills add garrytan/gstack --skill retro
Then invoke it when you need a weekly retrospective, a ship summary, or a sprint review. The most natural trigger phrases in the skill are “weekly retro,” “what did we ship,” and “engineering retrospective.”
Give it the right input
The retro install decision is easiest when your workspace already has commit activity and a consistent project directory. For best results, tell the agent the time window, team, and any focus area up front. For example: “Run retro for the last 7 days, emphasize release blockers, and call out ownership changes.” That is better than “summarize the project,” because it tells the skill how to frame the output.
Read these files first
Start with SKILL.md to understand the workflow and constraints, then inspect SKILL.md.tmpl if you want to see how the generated document is assembled. Since this repo does not include supporting rules/, resources/, or scripts, the two skill files are the main source of truth.
Practical workflow tips
Use retro after a meaningful work cycle, not midstream. If your repo has sparse commits, the output will be thinner, so add a clearer date range or ask for comparison with prior retros. For Project Management use, ask for outcomes, risks, and next actions rather than a narrative recap.
retro skill FAQ
Is retro only for engineering teams?
Mostly yes. retro is designed around code changes, work patterns, and delivery signals, so it fits engineering better than general business reporting. If your project has no meaningful commit trail, the skill has less to work with.
How is it better than a normal prompt?
A normal prompt can summarize a week once. retro is a reusable skill with built-in context queries for prior retros, timeline events, and learnings, so it can produce more consistent weekly output and track continuity over time.
Is retro beginner-friendly?
Yes, if you can describe the review period and what you want emphasized. You do not need to know the internals to use the skill, but stronger inputs produce better retros. Beginners usually get the best result by specifying a date range, a team, and one or two focus areas.
When should I not use retro?
Do not use retro if you want a deep architecture review, a bug triage report, or a product strategy memo. It is best for team progress reviews and trend-aware retrospectives, not broad analysis across unrelated goals.
How to Improve retro skill
Focus on the review question
The best retro usage starts with a clear question: ship velocity, ownership, quality, or team health. If you ask for everything at once, the retro will be generic. Pick the one decision you need to make after reading it.
Provide better ground truth
Give the skill a date range, repo name, release milestone, and any known incidents. Example: “Last week, main goal was release readiness; highlight regressions, handoffs, and unfinished work.” That helps the skill distinguish real progress from busy activity.
Watch for common failure modes
The main failure mode is over-optimizing for commit volume instead of meaningful progress. Another is vague praise that hides risk. If the first output is too broad, ask for a tighter split: shipped items, blocked items, team contributions, and next-week risks.
Iterate with a follow-up
After the first retro, refine it with one follow-up prompt: “Re-run retro with more emphasis on code quality and unresolved follow-ups” or “Summarize this for a PM audience in five bullets.” That is usually more effective than restarting from scratch and keeps the retro skill aligned with your actual workflow.