# Researchstack Learn

> Research memory skill for long-lived projects and researcher preferences. Use when Codex should record, inspect, prune, or apply durable knowledge about a paper project, venue strategy, experiment policy, writing weaknesses, reviewer risks, or repeated user preferences so later sessions become more context-aware.

- Skill: `lqf0624/researchstack-learn-2` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add lqf0624/researchstack-learn-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lqf0624/researchstack-learn-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: lqf0624 (https://skillmd.com/u/lqf0624)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lqf0624/researchstack-learn-2

---


<!-- AUTO-GENERATED for codex from researchstack v0.3.0. Edit source SKILL.md files, then regenerate from the source checkout. -->

# Research Learn

Read [../researchstack/references/memory.md](../researchstack/references/memory.md) first.

This skill manages the durable memory layer for `researchstack`.

Use it to:

- inspect current project memory,
- inspect or update cross-project researcher preferences,
- record important decisions after a session,
- prune stale or low-confidence memories,
- summarize what the pack already knows before a new workstream.

Default workflow:

1. Determine the project slug.
   - Do not use only the repo directory name.
   - Prefer `<repo-name>-<short-stable-id>` so similarly named repos do not share memory by accident.
   - Use the first 6 lowercase hex characters of `sha256(normalized-remote-or-root-path)` as the stable id.
   - If the user wants a concrete initializer, suggest `bun run memory:init -- --root <repo-root>`.
2. Read `~/.researchstack/projects/<slug>/memory.jsonl` if it exists.
3. Read `~/.researchstack/profile/preferences.json` if it exists.
4. Group what is known into:
   - stable program topic and paper portfolio,
   - thesis and scope,
   - topic state, method state, and rejected method candidates,
   - venue and reviewer risks,
   - experiment rules,
   - artifact or reproducibility rules,
   - writing and framing preferences.
5. If the user wants updates, append or merge only durable items.
6. If memory is stale or contradictory, call it out and recommend pruning.

When writing memory:

- prefer 1 to 3 high-signal entries over bulk dumping,
- keep titles short and searchable,
- store decisions, not meeting transcript noise,
- distinguish a program-level decision from a one-paper thesis,
- mark `source` honestly,
- use `confidence: low` for tentative inferences.

When updating existing project memory:

- append a new entry, do not rewrite old history,
- make the update explicit when it supersedes a prior decision,
- prefer the newest high-confidence entry when summarizing conflicts,
- point out contradictions instead of pretending they do not exist.

When reading memory into a later task, explicitly distinguish:

- remembered fact,
- current inference,
- new uncertainty that still needs verification.

If there is any doubt that two repos might collide, say so and pick a more specific slug before writing memory.