# Self Reflection

> Periodically review memory for contradictions, gaps, stale information, and controlled improvement proposals.

- Skill: `siddsachar/self-reflection` (Agent Skill)
- Install (CLI): `npx skillmds@latest add siddsachar/self-reflection`
- Raw SKILL.md: https://api.skillmd.com/api/skills/siddsachar/self-reflection/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: siddsachar (https://skillmd.com/u/siddsachar)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/siddsachar/self-reflection

---


When the user asks you to review your memories, check what you know, clean up your knowledge, or when you notice a potential contradiction in recalled memories, apply this process:

## Contradiction Detection

1. **Flag Conflicts** - When recalled memories contradict each other, surface the conflict to the user immediately. Do not silently pick one.
2. **Ask, Don't Assume** - Say exactly what conflicts you see and ask the user which version is correct. Then update the wrong memory and confirm the fix.
3. **Check Dates** - When you see a memory that might be outdated, mention it and ask whether it is still current.

## Memory Audit

4. **Get the Baseline** - Start with `wiki_stats` to see total articles, conversations, and vault health. Then use `search_memory` with broad terms to scan for coverage gaps.
5. **Systematic Sweep** - Use `search_memory` with broad category queries such as person, preference, fact, event, project, and place. Use `explore_connections` to visualize relationships and spot gaps.
6. **Review Quality** - Look for duplicates, stale entries, user-only connections, and missing links.
7. **Fix With Consent** - Update or `link_memories` during the audit when the user has confirmed the correction. Confirm each change.
8. **Rebuild After Cleanup** - After bulk updates, run `wiki_rebuild` to regenerate the wiki vault.
9. **Summarize** - After the audit, give a brief count of memories reviewed, updated, and linked, and flag anything that needs the user's input.

## Ongoing Awareness

10. **Correction Logging** - When the user corrects you on a fact, update the existing memory and briefly acknowledge the correction.
11. **Confidence Signals** - If you recall a memory but are not confident it is still accurate, say so and ask.

## Insights And Evolution

12. **Check Automated Insights** - During reflection, use `row_bot_status` with category `insights` to see active insights and linked proposals. Use category `evolution` to inspect proposals, action runs, rejection memory, and curator dry-run summaries.
13. **Present Controlled Actions** - For each active insight, summarize the category, severity, suggestion, linked proposal type, risk, confidence, and action status. Group related items by category.
14. **Use Proposals, Not Direct Edits** - Do not edit `insights.json`, memory files, skills, tool guides, settings, or code directly during reflection. For skill improvements, use `row_bot_create_skill` or `row_bot_patch_skill` to create proposals only, then ask the user to preview and approve with `row_bot_apply_proposal`.
15. **Send Feedback Separately** - For app bugs, tool/config problems, or system-health issues, create a redacted `row_bot_send_feedback` proposal instead of turning the issue into a skill. Do not include full logs or diagnostic bundles unless the user explicitly approves; the user can copy the report or submit it through the Row-Bot contact page.
16. **Learn From Outcomes** - If the user rejects a proposal, record the reason with `row_bot_reject_proposal`. Mark proposals verified only after explicit validation or user confirmation with `row_bot_verify_proposal`.