dcurlewis/.claude/skills/memory-validate

Review the staged memory updates in today's staging directory for quality control.

Process Guidelines

DO BEFORE ANYTHING ELSE: Follow all guidelines in Guidelines/memory-consolidation-guidelines.md

Prerequisites

Verify all four memory files exist in Memory/YYYYMMDD-memory-update/. If any are missing, stop and inform the user.

Memory/YYYYMMDD-memory-update/
├── memory-index.md
├── memory-people.md
├── memory-work.md
└── memory-context.md

Validation Framework

1. Language Quality

Check for extremist language (unless directly quoted from source), for example:

• Crisis, emergency, critical
• Urgent, immediate, pressing (unless deadline-specific)
• Failure, collapse, disaster
• Hemorrhaging, bleeding, dying (metaphorical)
• Perfect storm, under siege, existential threat
• Total, complete, absolute (absolutist qualifiers)

2. Factual Rigour

• Unsourced priority/severity assessments - Flag for user feedback or add source
• Predictive statements - Convert to current state
• Opinion vs fact - Remove opinions unless confirmed with the user
• Missing source attributions - Add "SOURCE NEEDED" marker and highlight to the user, or fix

3. Content Quality

For each file, assess:

• Coherence: Does the content flow logically?
• Completeness: Are key topics covered adequately?
• Clarity: Is the writing clear and scannable?
• Actionability: Are status markers and next steps clear?

4. Line Count Enforcement

Check each staged file against targets (as specified in "File Size Targets" section of Guidelines/memory-consolidation-guidelines.md).

• File over "max lines" limit: AUTO-FIX by condensing, then log what was condensed.

5. Staleness Detection

• Past dates in "immediate" or "this week" sections: AUTO-FIX by updating or removing; log the change
• Departed personnel still in memory files where context doesn't make sense: AUTO-FIX by removing (keep in stubs); log the change
• Terminated vendors still in memory files where context doesn't make sense: AUTO-FIX by removing (keep in stubs); log the change
• Completed/delivered projects lingering beyond a couple weeks: Flag for removal
• Items not refreshed or referenced by new source files: Flag for freshness review

Cross-reference against scan manifest: if a topic had new source files, verify the staged file reflects that new information.

6. Ownership and Deduplication

• Same information in multiple files: AUTO-FIX by keeping content in the correct file per ownership rules and reducing the other to a brief reference; log the change
• Entity facts that belong in stubs: Flag for removal from memory file and potential addition to stubs
• Content in wrong file per ownership rules: AUTO-FIX by relocating; log the change

7. Corrections Applied

• Cross-reference corrections.md entries against staged files
• Verify each correction has been applied
• Unapplied corrections: AUTO-FIX by applying the correction; log the change

Fix-It-Yourself Principle

Most validation issues have obvious fixes (deduplication, condensing, relocation, staleness removal). When the correct fix is clear:

1. Apply the fix directly to the staged files
2. Log what you did and why in the validation report under an "Auto-fixes applied" section

Only BLOCK (refuse to mark validation complete) when:

• The correct fix is genuinely ambiguous (e.g. unclear which file should own a piece of content, conflicting information with no obvious resolution)
• Fixing requires information you don't have (e.g. whether a person has actually departed, whether a project is truly completed)
• The issue is severe enough that a wrong fix could corrupt memory (e.g. removing content that might still be relevant but you can't tell)

When in doubt about whether to auto-fix: fix it. A slightly imperfect fix that keeps the pipeline moving is better than blocking on something that will get refined next cycle anyway.

Output

1. Apply any auto-fixes to the staged files.
2. Update Memory/YYYYMMDD-memory-update/memory-index.md:
   • set the Validation Completed value to True to indicate that this process has completed successfully (unless there are genuinely ambiguous blocking issues per the principle above).
3. Output a brief validation report for the user with:
   1. Summary: Pass/Fail with issue count and auto-fix count
   2. Auto-fixes applied: What was changed and why (one line per fix)
   3. Remaining issues by severity:
      • BLOCKING: Genuinely ambiguous issues that need user input
      • WARNING: Minor issues noted but not worth blocking (staleness flags, freshness review items)
      • NOTE: Optional improvements
   4. Line counts: Actual vs target for each file (after fixes)

Decision

• If genuinely ambiguous blocking issues remain: List the specific question you need answered, do not proceed
• If all issues were auto-fixed or are warnings only: Mark validation complete, inform user to run /memory-promote