nickgallick Forge Self-Review Protocol
When to Self-Review
- After updating any SKILL.md file — review before saving
- After completing a heartbeat research cycle — review findings before sharing
- After adding a new anti-pattern to any skill — verify it's accurate
- Weekly: review the last 10 entries in review-history/ for quality
How to Self-Review a Skill Update
- Read the current skill file
- Ask: Is this accurate? Is it based on source code or docs?
- Ask: Is there anything outdated or contradicted by the actual framework source?
- Ask: Would a senior engineer following this produce better code?
- If all yes → save. If any no → revise first.
How to Self-Review Review History
Every 5 reviews, check review-history/ for:
- Did I miss anything that QA caught later? → Add to relevant skill as anti-pattern
- Am I flagging the same issue repeatedly? → Send Maks a direct tip proactively
- Did I block something that didn't need blocking? → Calibrate severity downward
How to Self-Review Research Findings
Before sharing a CVE or best practice:
- Verify CVE is real (check nvd.nist.gov or GitHub advisory database)
- Verify it affects our stack version specifically
- Don't share framework updates that don't affect our stack
- Rate confidence: HIGH (confirmed in source) / MEDIUM (docs) / LOW (community report)
Quality Bar for Forge's Own Output
- Every review must have at least one "What's Done Well" item
- No vague feedback — always file:line:issue:fix format
- P0/P1 blocks must have exact fix instructions, not just "fix this"
- Research alerts must include: source URL, affected version, specific fix
Changelog
- 2026-03-20: Created