dvcrn Retrospective Agent
Use this skill to capture execution lessons in a controlled, auditable way.
This skill exists to improve how the agent works over time. It does not create a second factual memory system, rewrite identity, or invent autonomy.
Core principles
- Keep factual continuity in existing memory files
- Keep execution lessons separate and scoped
- Prefer reports and recommendations over automatic changes
- Promote patterns only after repeated evidence
- Never infer preferences from silence
- Never rewrite persona, config, or outbound behavior on your own
Memory split
Use existing memory for
- facts
- events
- decisions
- dates
- people
- open tasks
Examples:
memory/YYYY-MM-DD.md- agent
MEMORY.md - project
README.md
Use retrospective-agent files for
- repeated corrections
- workflow improvements
- tool failure patterns
- success patterns worth repeating
- project or domain execution lessons
Storage
Skill files live in:
workspace/skills/retrospective-agent/
Operational data lives in:
workspace/ops/retrospective-agent/
Expected first-pass files:
workspace/ops/retrospective-agent/corrections.mdworkspace/ops/retrospective-agent/weekly/workspace/ops/retrospective-agent/domains/workspace/ops/retrospective-agent/projects/workspace/ops/retrospective-agent/templates/
If the ops folder or expected files do not exist, create only the minimum needed for the current task. Do not create extra files "just in case".
Triggers
Use this skill when:
- the user asks for a retrospective or lessons learned
- a multi-step task ends and a short retro would be useful
- the user gives a reusable correction
- a process or tool fails in a reusable way
- a project needs scoped lessons for future work
- a weekly review is requested
Do not use this skill for:
- one-off instructions with no reusable lesson
- customer messaging drafts
- sensitive personal profiling
- fake automation or hidden monitoring claims
Operating modes
1. Post-task retrospective
Use after meaningful work.
Output:
- what went well
- what went wrong
- what to repeat
- what to change next time
- whether anything deserves logging
Keep it short and operational.
2. Correction logging
Use when an explicit correction reveals a reusable lesson.
Workflow:
- capture the exact correction
- classify it
- choose scope: project, domain, or global execution lesson
- append a concise entry if warranted
- recommend promotion only after repeated evidence
3. Weekly retrospective
Use on demand or when a scheduled review is explicitly requested.
Output:
- recurring wins
- recurring misses
- repeated patterns
- candidate updates to memory, README files, or skills
Scope hierarchy
Most specific wins:
- project
- domain
- global execution lesson
If scope is unclear, prefer domain over global. If still unclear, say so.
Promotion model
Use conservative states:
- observed
- repeated
- candidate rule
- confirmed rule
Suggested threshold:
- 1 occurrence: observed
- 2 occurrences: repeated
- 3 occurrences: candidate rule
Do not silently promote a candidate into durable agent behavior everywhere. Recommend the promotion and ask when confirmation matters.
Guardrails
Never:
- rewrite
SOUL.md - rewrite
IDENTITY.md - rewrite
USER.md - patch config
- send messages
- install companion skills without approval
- infer preferences from silence
- store credentials, secrets, or sensitive personal data
- claim autonomous monitoring unless a real scheduler exists
Workflow references
Read these only when needed:
references/workflow.mdreferences/promotion-rules.mdreferences/boundaries.md
Use templates from:
assets/templates/post-task-retro.mdassets/templates/weekly-retro.mdassets/templates/lesson-entry.md
Style
Be honest, compact, and boring in a good way. Avoid AGI theater, inflated claims, and vague self-improvement language. Prefer operational wording like "lesson", "pattern", "correction", and "recommended update" over dramatic wording like "optimize myself" or "evolve".
Output rule
Lead with the useful retrospective or lesson. Do not narrate the framework unless the user asks.