flonat-research 0.1.0

package/skills/code-archaeology/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: code-archaeology
+description: "Use when you need to review and understand old code, data, or analysis files."
+allowed-tools: Bash(ls*), Bash(cp*), Bash(mkdir*), Bash(git*), Read, Write, Edit, Glob, Grep
+argument-hint: [project-path]
+---
+
+# Code Audit Skill
+
+**CRITICAL RULE: Never delete data or code files.** Copy to legacy/, never move or delete originals.
+
+> Systematically review and understand old code, data, and analysis files.
+
+## Purpose
+
+Based on Scott Cunningham's workflow of reviving old projects - understanding what exists, documenting it, and making it safe to work with.
+
+**For formal audits with cross-language replication and referee reports, use the Referee 2 agent (`.claude/agents/referee2-reviewer.md`).** This skill is for understanding and documenting existing code, not formal verification.
+
+## When to Use
+
+- Returning to an old project after months/years
+- Taking over code from a coauthor
+- Before extending existing analysis
+- R&R requiring you to revisit old work
+
+## When NOT to Use
+
+- **Brand new projects** — use project-safety skill instead to set up structure
+- **Formal code verification** — use the Referee 2 agent for cross-language replication
+- **Quick code questions** — just ask directly, no need for full audit
+
+## Workflow
+
+1. **Explore the directory**:
+   - What files exist?
+   - What's the structure?
+   - When were things last modified?
+
+2. **Understand the pipeline**:
+   - What are the main scripts?
+   - What order do they run in?
+   - What data do they use?
+   - What outputs do they produce?
+
+3. **Document findings**:
+   - Create/update README.md
+   - Map data flows
+   - Note dependencies
+
+4. **Establish safety**:
+   - Create legacy/ folder
+   - Copy (don't move) originals
+   - Set up version control if not present
+
+5. **Create audit report**:
+   - What the code does
+   - Potential issues found
+   - Recommendations for cleanup
+
+## Safety Rules (from Scott Cunningham)
+
+```markdown
+1. Never delete data. Under no circumstances.
+2. Never delete programs. No do-files, no R scripts, nothing.
+3. Stay in this folder. Can go down, not up.
+4. Use a legacy folder. Move originals there for safekeeping.
+5. Copy, don't move. When reorganising, always copy from legacy.
+```
+
+## Prompt Template
+
+```
+I'm returning to an old project after [TIME]. Please help me understand what's here.
+
+1. Explore the directory and tell me what you find
+2. Identify the main analysis scripts and their order
+3. Map the data pipeline (inputs → processing → outputs)
+4. Note any potential issues (missing files, unclear code, etc.)
+5. Create a README documenting everything
+
+Before making ANY changes, create a legacy/ folder and copy everything there.
+```
+
+## Data Flow Mapping
+
+Understand how data moves through the project:
+- What raw data files exist?
+- What cleaning/transformation scripts run?
+- What intermediate files are created?
+- What outputs are generated?
+
+## Compare Datasets (if multiple versions exist)
+
+When you find multiple versions of the same data:
+- Side-by-side comparison of key variables
+- Identify where datasets diverge
+- Visualize differences geographically/temporally
+- Document which version to use going forward
+
+## Output Files
+
+After a code audit, you should have:
+
+```
+project/
+├── README.md           ← Project overview (generated)
+├── AUDIT.md            ← Audit findings and issues
+├── CLAUDE.md           ← Safety rules for this project
+├── legacy/             ← Protected original files
+├── docs/
+│   └── data_dictionary.md
+└── output/
+    └── audit_deck.pdf  ← Visual summary
+```
+
+## Questions to Answer
+
+- [ ] What is the research question?
+- [ ] What data is used?
+- [ ] What is the identification strategy?
+- [ ] What are the main results?
+- [ ] Are results reproducible from the code?
+- [ ] What assumptions are made?
+- [ ] What are the known limitations?
+- [ ] What would need to change to extend this?
+
+## Example Prompts
+
+**Initial exploration:**
+> "Read all the .do/.R/.py files in this project and create a summary of what each script does, including inputs and outputs."
+
+**Data comparison:**
+> "Compare dataset_v1.dta and dataset_v2.dta. Show me where they differ, with summary statistics and visualizations."
+
+**Documentation:**
+> "Create a README.md that documents this project's structure, data sources, and how to reproduce the main results."
+
+## Example Use
+
+"Audit my Brexit replication project - I haven't touched it in 8 months. Tell me what's there, what state it's in, and what I need to do to pick it back up."

package/skills/code-review/SKILL.md

@@ -0,0 +1,265 @@
+---
+name: code-review
+description: "Use when you need a quality review of R or Python research scripts."
+allowed-tools: Read, Glob, Grep
+argument-hint: [script-path or project-path]
+---
+
+# Research Code Review
+
+**Report-only skill.** Never edit source files — produce `CODE-REVIEW-REPORT.md` only.
+
+## When to Use
+
+- Before submitting a paper (check replication package quality)
+- After writing analysis scripts and before sharing with coauthors
+- When taking over someone else's research code
+- As part of the Referee 2 agent's formal audit pipeline
+
+## When NOT to Use
+
+- **Understanding old code** — use `/code-archaeology` first to map out what exists
+- **Formal verification** — use the Referee 2 agent for cross-language replication
+- **General software projects** — this is for research scripts, not applications
+
+## Workflow
+
+1. **Locate scripts**: Find all `.R`, `.py`, `.do`, `.jl` files in the project
+2. **Read each script** carefully
+3. **Score each category** (Pass / Fail / N/A)
+4. **Produce report**: Write `CODE-REVIEW-REPORT.md` in the project directory
+
+## 11 Review Categories
+
+### 1. Reproducibility
+
+| Check | Pass Criteria |
+|-------|--------------|
+| Random seeds | `set.seed()` / `random.seed()` / `np.random.seed()` set before any stochastic operation |
+| Relative paths | No hardcoded absolute paths (e.g., `/Users/username/...` or `C:\...`) |
+| Working directory | Script does not `setwd()` / `os.chdir()` — uses project-relative paths |
+| Session info | Script prints session info at end (`sessionInfo()` / `sys.version`) or documents environment |
+
+### 2. Script Structure
+
+| Check | Pass Criteria |
+|-------|--------------|
+| Header | Script begins with comment block: purpose, author, date, inputs, outputs |
+| Sections | Code organised into labelled sections (comments or `# ---- Section ----`) |
+| Imports at top | All `library()` / `import` statements at the top of the file |
+| Reasonable length | Single script < 500 lines; longer scripts should be split |
+
+### 3. Output Hygiene
+
+| Check | Pass Criteria |
+|-------|--------------|
+| No print pollution | No stray `print()` / `cat()` / `message()` dumping to console |
+| Outputs saved | Key results saved to files, not just printed |
+| Clean console | Running the script does not produce walls of text |
+
+### 4. Function Quality
+
+| Check | Pass Criteria |
+|-------|--------------|
+| Documentation | Functions have comments explaining purpose, inputs, outputs |
+| Naming | Function names are descriptive verbs (`estimate_ate`, not `f1`) |
+| Defaults | Reasonable defaults for optional parameters |
+| No side effects | Functions don't modify global state |
+
+### 5. Domain Correctness
+
+| Check | Pass Criteria |
+|-------|--------------|
+| Estimator matches paper | The estimator used matches what the paper claims |
+| Weights | If weighted: weights sum to expected value, correct application |
+| Standard errors | Clustering / HC / bootstrap matches paper specification |
+| Sample restrictions | Filters match the paper's sample description |
+| Variable construction | Variables constructed as described in the paper |
+
+### 6. Figure Quality
+
+| Check | Pass Criteria |
+|-------|--------------|
+| Dimensions specified | Figure size set explicitly (not default) |
+| Transparency/resolution | Appropriate for publication (300+ DPI for raster, vector preferred) |
+| Saved to file | Figures saved with `ggsave()` / `plt.savefig()`, not just displayed |
+| Labels | Axes labelled, legend present where needed, title informative |
+| Colour | Colourblind-friendly palette; not relying on red/green distinction |
+
+### 7. Data Persistence
+
+| Check | Pass Criteria |
+|-------|--------------|
+| Intermediate objects saved | Expensive computations saved (`saveRDS()` / `pickle.dump()` / `.parquet`) |
+| Load before recompute | Script checks for saved objects before rerunning expensive operations |
+| Output format | Final outputs in portable format (CSV, parquet — not just `.RData`) |
+
+### 8. Dependencies
+
+| Check | Pass Criteria |
+|-------|--------------|
+| Declared at top | All `library()` / `import` at the start of the script |
+| Versions documented | `renv.lock` / `requirements.txt` / `pyproject.toml` exists |
+| No unnecessary packages | Each loaded package is actually used |
+| Installation instructions | README or comment explains how to set up the environment |
+
+### 9. Python-Specific
+
+*Score N/A if no Python files.*
+
+| Check | Pass Criteria |
+|-------|--------------|
+| Type hints | Functions have type annotations for parameters and return values |
+| Docstrings | Functions have docstrings (not just comments) |
+| uv usage | Uses `uv` for environment management (per project conventions) |
+| f-strings | Uses f-strings, not `.format()` or `%` formatting |
+
+### 10. R-Specific
+
+*Score N/A if no R files.*
+
+| Check | Pass Criteria |
+|-------|--------------|
+| tidyverse consistency | Doesn't mix base R and tidyverse for the same operation |
+| Assignment operator | Uses `<-` not `=` for assignment |
+| Boolean values | Uses `TRUE`/`FALSE`, not `T`/`F` |
+| Pipe consistency | Uses one pipe style consistently (`%>%` or `|>`) |
+
+### 11. Cross-Language Verification
+
+*Score N/A if the project has no numerical results or only uses one language.*
+
+| Check | Pass Criteria |
+|-------|--------------|
+| Replication directory | `code/replication/` (or equivalent) exists with cross-language scripts |
+| Two-language coverage | Key numerical results reproduced in a second language (e.g., R results verified in Python or vice versa) |
+| Result comparison | Scripts compare outputs and report discrepancies (tolerance-based, not exact match) |
+| Precision threshold | Numerical outputs compared to 6+ decimal places — discrepancies at lower precision indicate real bugs |
+| Documentation | README or comments explain what is being replicated and acceptable tolerance |
+
+#### Why Cross-Language Replication Works
+
+Different languages produce different hallucination patterns when AI-assisted. An error in a Python implementation is unlikely to appear identically in R (or vice versa), making discrepancies easy to spot. This is the core insight from Scott Cunningham's Referee 2 protocol.
+
+#### How to Set Up
+
+1. Create `code/replication/` with scripts that independently implement key numerical results in a second language
+2. Write a comparison script that loads outputs from both languages and reports discrepancies at 6+ decimal places
+3. Document what is being replicated, which results are covered, and the acceptable tolerance (e.g., 1e-6 for coefficients, 1e-4 for standard errors)
+
+## Confidence Filtering
+
+- Only report issues where you are >80% confident they are genuine problems
+- Consolidate similar findings (e.g., 5 instances of the same naming issue = 1 finding with count)
+- For borderline cases, note uncertainty: "Possible issue (medium confidence): ..."
+- Never pad the report with low-confidence observations to appear thorough
+
+## Scorecard
+
+| # | Category | Result | Notes |
+|---|----------|--------|-------|
+| 1 | Reproducibility | Pass/Fail | |
+| 2 | Script structure | Pass/Fail | |
+| 3 | Output hygiene | Pass/Fail | |
+| 4 | Function quality | Pass/Fail | |
+| 5 | Domain correctness | Pass/Fail | |
+| 6 | Figure quality | Pass/Fail | |
+| 7 | Data persistence | Pass/Fail | |
+| 8 | Dependencies | Pass/Fail | |
+| 9 | Python-specific | Pass/Fail/N/A | |
+| 10 | R-specific | Pass/Fail/N/A | |
+| 11 | Cross-language verification | Pass/Fail/N/A | |
+
+**Overall: X/11 Pass** (adjust denominator for N/A categories)
+
+## Quality Scoring
+
+Apply numeric quality scoring using the shared framework and skill-specific rubric:
+
+- **Framework:** [`../shared/quality-scoring.md`](../shared/quality-scoring.md) — severity tiers, thresholds, verdict rules
+- **Rubric:** [`references/quality-rubric.md`](references/quality-rubric.md) — issue-to-deduction mappings for this skill
+
+Start at 100, deduct per issue found, apply verdict. Insert the Score Block into the report after the scorecard.
+
+## Report Format
+
+```markdown
+# Code Review Report
+
+**Project:** [path]
+**Date:** YYYY-MM-DD
+**Scripts reviewed:** [list]
+**Languages:** R / Python / Both
+
+## Scorecard
+
+[Table above, filled in]
+
+## Detailed Findings
+
+### Category 1: Reproducibility
+**Result: Pass/Fail**
+
+[Specific findings with file:line references]
+
+### Category 2: Script Structure
+...
+
+[Continue for all 11 categories]
+
+## Priority Fixes
+
+1. [Most important issue — what to fix first]
+2. [Second most important]
+3. [Third]
+
+## Quality Score
+
+| Metric | Value |
+|--------|-------|
+| **Score** | XX / 100 |
+| **Verdict** | Ship / Ship with notes / Revise / Revise (major) / Blocked |
+
+### Deductions
+
+| # | Issue | Tier | Deduction | Category |
+|---|-------|------|-----------|----------|
+| 1 | [description] | [tier] | -X | [category] |
+| | **Total deductions** | | **-XX** | |
+
+## Positive Observations
+
+[Things done well — important for morale and learning]
+```
+
+## Council Mode (Optional)
+
+For complex codebases or high-stakes replication packages, run the code review across multiple LLM providers. Different models have different strengths: some excel at spotting statistical errors, others at code structure or reproducibility issues.
+
+**Trigger:** "Council code review" or "thorough code review"
+
+**How it works:**
+1. Each model independently scores all 11 categories against the same scripts
+2. Cross-review: models evaluate each other's findings — catching false positives and missed issues
+3. Chairman synthesis: produces a single `CODE-REVIEW-REPORT.md` with the union of confirmed findings
+
+**Invocation (CLI backend):**
+```bash
+cd packages/cli-council
+uv run python -m cli_council \
+    --prompt-file /tmp/code-review-prompt.txt \
+    --context-file /tmp/scripts-content.txt \
+    --output-md /tmp/code-review-council.md \
+    --chairman claude \
+    --timeout 180
+```
+
+See `skills/shared/council-protocol.md` for the full orchestration protocol.
+
+**Value:** Moderate to high — most valuable for domain correctness (Category 5) and cross-language verification (Category 11), where different models may catch different statistical or logical errors.
+
+## Cross-References
+
+- **`/code-archaeology`** — For understanding unfamiliar code before reviewing it
+- **Referee 2 agent** — For formal cross-language replication and verification (Category 11 flags the absence; Referee 2 does the actual replication)
+- **`/proofread`** — For the paper that accompanies this code

package/skills/code-review/references/quality-rubric.md

@@ -0,0 +1,67 @@
+# Quality Rubric: Code Review
+
+> Scoring rubric for `/code-review`. Uses the shared framework in [`../../shared/quality-scoring.md`](../../shared/quality-scoring.md).
+
+## Deduction Table
+
+### Blocker (-100)
+
+| Issue | Deduction | Notes |
+|-------|-----------|-------|
+| Syntax error preventing script from running | -100 | Script is broken |
+| Missing critical dependency with no install instructions | -100 | Cannot reproduce without guessing |
+
+### Critical (-15 to -25)
+
+| Issue | Deduction | Notes |
+|-------|-----------|-------|
+| Numerical project missing cross-language replication scripts | -20 | Once per project — no independent verification of results |
+| Hardcoded absolute path (`/Users/...`, `C:\...`) | -20 | Per unique path — breaks on any other machine |
+| Domain correctness bug (wrong estimator, wrong sample restriction) | -20 | Per instance — produces wrong results |
+| No random seed before stochastic operation | -15 | Per stochastic block — results not reproducible |
+| `setwd()` / `os.chdir()` in script | -15 | Breaks portability |
+| Weights applied incorrectly or not summing to expected value | -15 | Domain error |
+| Standard errors don't match paper specification | -15 | Domain error |
+
+### Major (-5 to -14)
+
+| Issue | Deduction | Notes |
+|-------|-----------|-------|
+| No script header (purpose, author, date, I/O) | -10 | Per script |
+| No environment documentation (renv.lock, requirements.txt) | -10 | Once per project |
+| Expensive computation not cached | -8 | Per operation |
+| Function without documentation | -5 | Per function |
+| Stray print/cat pollution | -5 | Per script with pollution |
+| Script > 500 lines without splits | -5 | Per script |
+| Loaded but unused package | -5 | Per package |
+| Figures not saved to file (only displayed) | -5 | Per figure |
+
+### Minor (-1 to -4)
+
+| Issue | Deduction | Notes |
+|-------|-----------|-------|
+| Non-descriptive function name (`f1`, `do_stuff`) | -3 | Per function |
+| Missing type hints (Python) | -3 | Once per script, not per function |
+| `=` instead of `<-` for assignment (R) | -2 | Once for the pattern |
+| Mixed pipe styles (`%>%` and `|>`) | -2 | Once for the pattern |
+| `T`/`F` instead of `TRUE`/`FALSE` (R) | -2 | Once for the pattern |
+| Default figure dimensions (not explicitly set) | -2 | Per figure |
+| Non-colourblind-friendly palette | -2 | Per figure |
+| Final output in non-portable format (`.RData` only) | -3 | Per output |
+| Missing session info at end of script | -1 | Per script |
+
+## Category Mapping
+
+| Rubric category | SKILL.md check category |
+|----------------|------------------------|
+| Reproducibility | Category 1 |
+| Script structure | Category 2 |
+| Output hygiene | Category 3 |
+| Function quality | Category 4 |
+| Domain correctness | Category 5 |
+| Figure quality | Category 6 |
+| Data persistence | Category 7 |
+| Dependencies | Category 8 |
+| Python-specific | Category 9 |
+| R-specific | Category 10 |
+| Cross-language verification | Category 11 |

package/skills/consolidate-memory/SKILL.md

@@ -0,0 +1,208 @@
+---
+name: consolidate-memory
+description: "Use when you need to prune duplicates and merge overlapping entries in MEMORY.md files."
+allowed-tools: Read, Write, Edit, Glob, Grep, AskUserQuestion
+argument-hint: "[project-path or 'all' for global consolidation]"
+---
+
+# Consolidate Memory
+
+Periodic refinement of `MEMORY.md` files across projects. Prunes redundant entries, merges overlapping knowledge, generates higher-order abstractions from accumulated patterns, and removes stale or superseded entries.
+
+Inspired by npcsh's knowledge graph sleep/dream cycles — memory consolidation applied to research project knowledge.
+
+## When to Use
+
+- Monthly maintenance (pair with `/system-audit`)
+- When a `MEMORY.md` exceeds 100 entries
+- After completing a major project milestone (e.g., paper submission)
+- When starting a new session and `MEMORY.md` feels cluttered
+- When the same correction keeps appearing across multiple projects
+
+## When NOT to Use
+
+- During active work sessions — consolidation is a maintenance task
+- When `MEMORY.md` has fewer than 10 entries — not enough to consolidate
+- Immediately after recording `[LEARN]` tags — let knowledge accumulate first
+
+## Modes
+
+Ask the user which mode to run:
+
+| Mode | Scope | What it does |
+|------|-------|-------------|
+| **Project** (default) | Single project's `MEMORY.md` + `.claude/state/personal-memory.md` | Consolidate both tiers |
+| **Global** | All `MEMORY.md` + personal-memory files across projects + Task Management | Consolidate all, cross-pollinate shared patterns |
+
+## Workflow
+
+### Phase 1: Sleep (Consolidation)
+
+Read the target `MEMORY.md` file(s) and `.claude/state/personal-memory.md` (if it exists) and perform:
+
+#### 1.1 Duplicate Detection
+
+Find entries that say the same thing in different words.
+
+**Signals:**
+- Same correction direction (wrong → right) with different phrasing
+- Same file/variable referenced in multiple entries
+- Entries from different dates that record the same learning
+
+**Action:** Merge into a single entry, keeping the most precise wording. Note the merge in a comment: `<!-- merged from 2 entries -->`.
+
+#### 1.2 Contradiction Resolution
+
+Find entries that contradict each other (e.g., "use X" in one entry, "don't use X" in another).
+
+**Signals:**
+- Opposite correction directions for the same variable/convention
+- Entries where a later one supersedes an earlier one
+
+**Action:** Keep the most recent/correct entry. Flag contradictions for user review if the resolution isn't obvious.
+
+#### 1.3 Staleness Detection
+
+Find entries that are no longer relevant.
+
+**Signals:**
+- References to files, variables, or conventions that no longer exist in the project
+- Entries about bugs that have been fixed
+- Entries about tools or APIs that have changed
+- Entries marked with dates older than 6 months with no recent reinforcement
+
+**Action:** Mark as `[STALE?]` and present to user for confirmation before removing. Never auto-delete.
+
+#### 1.4 Tier Routing Check
+
+Check whether entries are in the correct tier (see `learn-tags` rule for the two-tier system).
+
+**Promotion candidates** (personal-memory → MEMORY.md):
+- Entries in `.claude/state/personal-memory.md` that would help a collaborator on a different machine
+- Local workarounds that turned out to be general conventions
+- Tool quirks that apply to all machines (not just this one)
+
+**Demotion candidates** (MEMORY.md → personal-memory):
+- Entries in `MEMORY.md` that reference local paths, machine-specific tool versions, or environment quirks
+- Workarounds that only apply to this specific setup
+
+**Action:** Present promotion/demotion suggestions to the user. Move entries only after explicit approval.
+
+#### 1.5 Strengthening
+
+Entries that have been independently confirmed multiple times are high-confidence knowledge.
+
+**Signals:**
+- Same pattern recorded from different sessions
+- Corrections reinforced by compilation errors or test failures
+- Conventions confirmed by supervisor feedback
+
+**Action:** Move to the top of their section. Add `[CONFIRMED]` marker if supported by 3+ independent occurrences.
+
+### Phase 2: Dream (Abstraction)
+
+Generate higher-order patterns from the accumulated entries.
+
+#### 2.1 Cross-Entry Patterns
+
+Look for patterns that span multiple entries:
+
+- "Every time we work with X, we hit Y" → Record as a general rule
+- "We always use convention A for project type B" → Record as a convention
+- "Corrections in category C cluster around the same mistake" → Record the root cause
+
+#### 2.2 Cross-Project Patterns (Global mode only)
+
+When consolidating across all projects, look for knowledge that applies everywhere:
+
+- Notation conventions used consistently across 3+ projects → Promote to global MEMORY.md
+- The same code pitfall appearing in multiple projects → Record once with cross-references
+- Citation corrections that apply to shared bibliography entries → Consolidate
+
+#### 2.3 Abstraction Generation
+
+For each pattern found, generate an abstraction:
+
+```markdown
+## Abstraction: [Name]
+
+**Pattern:** [What keeps happening]
+**Root cause:** [Why it happens]
+**Prevention:** [How to avoid it in future]
+**Evidence:** [Which entries support this]
+```
+
+Present abstractions to the user. Only write the ones they approve.
+
+### Phase 3: Write
+
+#### 3.1 Restructure
+
+Rewrite `MEMORY.md` with:
+1. **Abstractions** at the top (new section: `## Patterns`)
+2. **Confirmed entries** next (high-confidence knowledge)
+3. **Regular entries** in their standard sections (Notation Registry, Citations, Key Decisions, Anti-Patterns, Code Pitfalls)
+4. **Stale entries removed** (only those confirmed by user)
+
+If `.claude/state/personal-memory.md` exists, also rewrite it with consolidated machine-specific entries. Apply any user-approved promotions (move to MEMORY.md) and demotions (move from MEMORY.md to personal-memory).
+
+#### 3.2 Diff Report
+
+Before writing, show a summary:
+
+```markdown
+## Consolidation Summary
+
+| Action | Count |
+|--------|-------|
+| Duplicates merged | X |
+| Contradictions resolved | X |
+| Stale entries flagged | X |
+| Stale entries removed | X (user-confirmed) |
+| Entries strengthened | X |
+| Abstractions generated | X |
+| Tier promotions (personal → generic) | X |
+| Tier demotions (generic → personal) | X |
+| Cross-project promotions | X (global mode) |
+
+### Entries Before: XX
+### Entries After: YY
+### Net reduction: ZZ
+```
+
+#### 3.3 Confirmation
+
+**Always show the full proposed MEMORY.md before writing.** Wait for explicit approval. The user may want to keep entries flagged as stale, adjust abstractions, or revert merges.
+
+## MEMORY.md Sections (Reference)
+
+Standard sections from the `learn-tags` rule:
+
+| Section | Columns |
+|---------|---------|
+| **Patterns** | Pattern / Root cause / Prevention / Evidence (NEW — added by this skill) |
+| **Notation Registry** | Variable / Convention / Anti-pattern |
+| **Estimand Registry** | What we estimate / Identification / Key assumptions |
+| **Citations** | One-liner corrections |
+| **Key Decisions** | Decision / Rationale / Date |
+| **Anti-Patterns** | What went wrong / Correction |
+| **Code Pitfalls** | Bug / Impact / Fix |
+
+## Global MEMORY.md Location
+
+The Task Management MEMORY.md at the project root:
+```
+$TM/MEMORY.md
+```
+
+Also check the auto-memory directory (path varies by machine — glob for it):
+```
+~/.claude/projects/-Users-user-*Task-Management/memory/MEMORY.md
+```
+
+## Cross-References
+
+- **`/system-audit`** — Run consolidation as part of periodic maintenance
+- **`/learn`** — Creates the entries that this skill consolidates
+- **`[LEARN]` tags** (rule) — The tagging system that feeds MEMORY.md
+- **`/general-session-recap`** — May surface entries worth recording before consolidation