Use when documenting an engineering work session that should become durable project memory, including planning, investigation, implementation, debugging, validation, operations, or hardware work, especially when questions were asked, options were considered, actions were taken, outcomes were observed, failures occurred, decisions were made, or project history may need updating.
Preserve durable engineering memory. Do not reduce the session to only the final outcome when the path, questions, failures, or decisions matter to future work.
Use this skill when the session includes any of:
Do not use this for generic meeting notes, casual chat, or trivial work with no continuity value.
If the session should count as durable project memory, preserve enough evidence that a future engineer can understand what happened, why it happened, and what remains.
If a fact matters but is unknown, mark it unknown. Do not guess.
Unless truly not applicable, preserve:
| Mode | Use When | Expected Output |
|---|---|---|
| Full | planning plus work, meaningful investigation, or durable continuity needed | detailed session record in the repo's natural docs/history location |
| Short | focused work still worth preserving | shorter note or history entry |
| Micro | too small for a standalone record | small continuation note only if needed |
Default to Full when the work would be hard to reconstruct later from the final diff, issue state, or final outcome alone.
Collect or confirm:
Ask for missing high-value facts instead of smoothing over them.
Adapt to the repository instead of forcing one format.
Use the repo's existing conventions when available:
If the repo has no clear session-log convention, preserve the session in the most appropriate existing project-history location. Do not create a new documentation structure unless the user wants one.
If the session included clarifying questions, competing approaches, or a recommendation, preserve the useful parts of that path.
Do not keep raw conversation transcripts. Preserve the engineering substance:
Keep the actions that matter:
Do not keep noisy scratch work unless it teaches something reusable.
If the session produced durable project changes, update the repo's history surface when appropriate.
Examples:
CHANGELOG.mdAsk: "Would a future contributor expect this change or decision to appear in project history?"
Before considering the session documented, do a narrow check for likely omissions.
Examples:
Keep this audit lightweight. Do not turn it into a full archaeology pass.
| If the session includes... | Preserve at minimum |
|---|---|
| planning and clarifying questions | goals, constraints, questions, options, decision |
| implementation work | actions, affected area, verification, next steps |
| failed attempts | the important failure and what corrected it |
| unresolved items | explicit open questions or follow-ups |
| durable project change | project-history update if the repo uses one |
Fix: preserve the planning path when the decision would otherwise be hard to reconstruct.
Fix: keep useful engineering continuity, not noisy transcript-level chronology.
Fix: keep the failures that changed understanding, exposed a pitfall, or affected the final decision.
Fix: adapt to the repository's actual documentation conventions.
Fix: unresolved items are often the most important bridge to the next session.