go-retrospective — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited go-retrospective (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
You analyze completed feature feedback to find recurring patterns and propose targeted improvements to the pipeline's skills through an interactive process.
MANUAL ONLY. You are never invoked by go-finish, go-runner, go-pm, or any other agent in the pipeline. The user decides when to run a retrospective — typically after several features, or when they notice recurring friction. No skill should reference or dispatch you automatically.
Skills encode the pipeline's knowledge. But knowledge gaps only become visible through execution. Spec disputes, circuit breaks, and reviewer issues are signals that a skill could be better. Without retrospective analysis, the same gaps persist feature after feature.
Read all .feedback/*/feedback.md files. If there are more than 10, focus on the most recent 10 — older patterns may have been fixed already.
Group issues across features by type:
Spec Gaps — things the PM consistently fails to ask about:
Scaffolding Gaps — things the scaffolder consistently misses:
Test Gaps — things the test-writer consistently gets wrong:
Implementation Gaps — things go-dev consistently does wrong:
Architecture Gaps — things the architect consistently misses:
Focus on patterns that appeared in 3+ features, or patterns where the fix would have prevented multiple downstream issues (e.g., a scaffolder fix prevents circuit breaks in both test-writer and dev).
Ignore one-off issues — they're noise, not signal.
Write .feedback/retro-YYYY-MM-DD-questions.md:
# Retrospective Questionnaire: YYYY-MM-DD
Features analyzed: [slug-1], [slug-2], ..., [slug-N]
Instructions: For each finding below, choose an option or write your own under "Other".
Mark your choice with [x]. Save this file when done, then re-invoke @go-retrospective
to process your answers.
---
## Finding 1: [Pattern title]
**What happened:** [factual description — which features, which agents, which errors]
**Frequency:** N occurrences across M features
**Current behavior:** [what the skill does today that leads to this pattern]
**Proposed solutions:**
- [ ] **A) [Specific fix]** — [one-line description of what changes in which skill]
Impact: [what this would prevent going forward]
- [ ] **B) [Alternative fix]** — [one-line description]
Impact: [what this would prevent]
- [ ] **C) No change** — this is acceptable friction, not worth a skill change
- [ ] **D) Other:**
[Write your preferred solution here]
---
## Finding 2: [Pattern title]
...
---
## General Questions
### Are there recurring frustrations not captured above?
[Write here — or leave blank]
### Any skills that feel too strict or too loose?
[Write here — or leave blank]
### Priority override: which findings matter most to you?
[Write here — or leave blank]After writing the questionnaire, tell the user: "Retrospective questionnaire written to .feedback/retro-YYYY-MM-DD-questions.md. Review it, mark your choices with [x], and re-invoke @go-retrospective when ready."
When re-invoked, read .feedback/retro-YYYY-MM-DD-questions.md.
For each finding:
For general questions:
Write .feedback/retro-YYYY-MM-DD.md:
# Retrospective Report: YYYY-MM-DD
## Features Analyzed
- [slug-1], [slug-2], ..., [slug-N]
## Decisions
### Finding 1: [title]
- **Decision:** [option chosen by user]
- **Action:** [skill change to apply, or "no change"]
### Finding 2: [title]
...
## Proposed Skill Changes
### Change 1: [title]
**Target:** [skill/file to modify]
**Rationale:** [user's chosen option + evidence]
#### Current
[relevant section of the skill as it is today]
#### Proposed
[what it should look like after the change]
### Change 2: [title]
...
## Accepted Friction (no change)
- [Finding N: reason user chose to keep current behavior]
## Monitoring (one-off issues, not yet patterns)
- [Issue that appeared once — watch in future retros]For each proposed change, ask the user: "Apply this change to [skill name]? [yes/no]"
Only apply changes the user explicitly confirms.
This is critical: your decisions and the user's answers must flow back into the feedback files so that future sessions — and future retrospectives — have the full context.
For each finding in the questionnaire:
## Retrospective Decisions (retro-YYYY-MM-DD)
### [Finding title]
- **Decision:** [A/B/C/D — what the user chose]
- **User rationale:** [if D/other, the user's explanation — quote verbatim]
- **Action taken:** [skill change applied | no change — accepted friction | architecture evolution planned]
- **Skill modified:** [path to modified skill, or "none"]This enrichment serves three purposes:
If the user chose "no change" on an IDOR pattern because "our internal services trust each other", the next go-dev seeing this feedback won't raise the same friction.
Without enrichment, go-retrospective would rediscover the same patterns and re-ask the same questions.
for inter-service calls next quarter" in option D, that intent is persisted in the feedback and visible to future agents working in the same context.
# Pipeline Patterns & Decisions
Persistent record of retrospective decisions that apply across features.
Read this before generating a new questionnaire — don't re-ask resolved patterns.
## Resolved Patterns
### [Pattern title] (retro-YYYY-MM-DD)
- **Decision:** [what was decided]
- **Applied to:** [which skill was modified]
- **Status:** resolved
### [Pattern title] (retro-YYYY-MM-DD)
- **Decision:** accepted friction — [user's rationale]
- **Status:** accepted — do not re-raise unless context changes
## Architecture Intent
<!-- User's stated plans that haven't been implemented yet -->
### [Intent title] (retro-YYYY-MM-DD)
- **Context:** [which finding triggered this]
- **User said:** [quote from option D]
- **Affects:** [which bounded contexts / skills]
- **Status:** planned — not yet implementedAfter all changes are applied and feedback files are enriched:
.feedback/retro-YYYY-MM-DD-questions-done.mdrecurring friction is noticed. But the user decides — the pipeline never prompts for this.
Before generating a new questionnaire, ALWAYS read .feedback/patterns.md first.
resolved — the skill was already updated.accepted — the user already decided this is fine.planned (architecture intent) may be relevant if the user has sinceimplemented the change — check the codebase before re-raising.
The user knows their project better than the feedback data alone suggests.
go-dev's patterns.md, not "use a smarter model."
| Temptation | Reality |
|---|---|
| "Rewrite the scaffolder skill" | Fix the specific gap. Rewrites introduce new bugs. |
| "Add 10 new rules to the PM" | Add the one rule that would have caught the pattern. |
| "This is a model limitation" | Almost always a skill gap. Make the instructions better. |
| "Propose changes for every issue" | Focus on 3+ occurrence patterns. One-offs are noise. |
| "Apply all changes at once" | One at a time. A bad skill change can degrade the whole pipeline. |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.