SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillslight-memory-pm

light-memory-pm

Coding & development

View repository

Updated 10-16 06:23

About this skill

Context Management, Memory Persistence, and Research Project Management

Persistence (using the Light memory system + project repository db09)

  • Write cross-session facts to memory files (user/feedback/project/reference), and add an index line in MEMORY.md. Among these, the "cross-project process lessons" section of the feedback memory slot is structurally implemented as the top-level db09 lessons.md(at the same level as projects/ ; format see below); the feedback memory file itself still stores personal-preference-type feedback.
  • Write project-level state to the project_card in db09:project_name, goal, current_stage, confirmed_idea, data_status, method_status, experiment_status, paper_status, ppt_status, code_status, risk_list, next_actions, decision_log, version_history。
  • Always convert relative dates to absolute dates before storing.
  • Two-layer memory model(drawing on the scope design of LangGraph checkpointer/Store and mem0): session-level state (≈thread_id, short-term, may be lost as the session is compressed) and project-level state (≈cross-session Store/db09, long-term, persisted by "project" namespace) are managed separately. Key facts must be explicitly written even if they can be automatically extracted—automatic memory (mem0-style LLM extraction) will miss records, and db09 is the authoritative source.

Memory Writing Mechanism (signature feature, hard definition)

Four types of memory fileswhere to store, what format, when to write, when to read, follow this exactly, do not omit.

Where to store (on-disk paths)

All stored in db09, one independent directory per project (relative to this skill directory it is ../../databases/db09-projects/projects/<project_name>/）：

databases/db09-projects/projects/<project_name>/
├── project_card.md       项目卡：14 字段总览（next_actions 在此）
├── terminology.md        术语/指标/创新点统一定义表（供 a07）
├── decision_log.md       重大决策时间线
└── version_history.md    论文/PPT/图表/代码各版本记录
（可选子目录 literature/ reviews/ submissions/ 见 db09 README）

<project_name> Use a hyphenated English slug (e.g., dairygoat-detect-track). Existing instances can be directly referenced:projects/dairygoat-detect-track/(all four files complete; version_history.md only records the current state before a formal version is released, and does not fabricate historical versions).

What format (exact structure of the four files, templates see db09 project_card_template.md）

  1. project_card.md — top YAML frontmatter (project_name / created absolute date), body # 项目卡：<中文标题>, then use a ```yaml code block containing 14 fields:project_name, goal, current_stage, confirmed_idea, data_status, method_status, experiment_status, paper_status, ppt_status, code_status, risk_list, next_actions, the last two fields write decision_log: 见 decision_log.md、version_history: 见 version_history.md. For multiline fields use | block scalar.
  2. terminology.md — Markdown table:| 类别 | 标准叫法 | 缩写 | 英文 | 备注 |, categories are Method/Dataset/Metric/Innovation Point; the standard wording of innovation point rows must be aligned word-for-word with the paper/PPT/software copyright.
  3. decision_log.md — one entry per line:- [YYYY-MM-DD] 决策 — 理由 — 来源(m03/m04/m14…). Append only, do not rewrite, preserve the timeline.
  4. version_history.md — one entry per line:- [YYYY-MM-DD] 材料(论文/PPT/图/代码) vN — 变更摘要, aligned with git tags (see "Management Tool Mapping" below).

What to record

Project background, research questions, confirmed ideas, data situation, experiment progress, respective versions of paper/PPT/figures/code, submission and review records, user preferences (writing style/tools/format), target journals, format requirements, important decisions (decision_log). Do not record: code structure, git history, things that can be seen directly from the repository.

Project Phase Breakdown

Break the project into: literature research → idea conception → plan confirmation → data preparation → experiment implementation → result analysis → paper writing → figure production → submission preparation → defense presentation → achievement transformation. For each phase establish:

  • Task list(checkable),Timeline/Gantt、Milestones、Risk list、Version history。
  • When mapped to tools: one phase = one milestone (GitHub milestone, with a due date), tasks within a phase = entries with - [ ] checkboxes, risk items marked with risk markers.- [x] is used for completed items, to facilitate automatic progress tracking.

Management tool mapping (see a09; for specific usage/endpoints/parameters see references.md)

  • Code/text/manuscript versions→Git: milestones use annotated tags git tag -a v1.2.0(only annotated tags are recognized by git describe ), follow SemVer, papers/PPTs are also tagged and aligned with version_history; CHANGELOG follows Keep a Changelog; large files go to DVC;git push --tags only uploads.
  • Data/experiments→DVC / MLflow / W&B：DVC dvc add generates pointers,dvc.yaml defines stages,dvc exp run+metrics diff；MLflow start_run+log_param/metric/artifact links run_id; W&B init/log+Artifacts lineage+Sweeps, record run URL. data_status/experiment_status are linked to the corresponding commit/run.
  • Literature→Zotero、Project knowledge→Obsidian/Notion/Logseq/Markdown、Progress→README+CHANGELOG: for their respective API base URLs, rate limits, and field mappings see references.md.

Update discipline (mandatory)

Each time you complete: literature search, idea revision, experiment run, paper revision, PPT revision, submission revision—immediatelyupdate the corresponding fields in db09 and decision_log, to avoid losing long-term project context.

Trigger→write mapping: idea finalized→modify confirmed_idea + append decision_log; experiment finished→modify experiment_status + next_actions; new version of paper/PPT/code→modify the corresponding *_status + append version_history (and create a git tag); plan changes/trade-offs→append decision_log; new terminology/metric/innovation named→add to terminology.md.

Cross-project lesson write-back (restrained, to avoid noise): only when a decision produced aprocess lesson reusable across projects—pitfalls, rejected by reviewers/advisor, reproduction failure, a process that significantly saves time/avoids pitfalls—only then, while appending to decision_log,at the same timewrite back one lesson to the top-level lessons.mdof db09 (format:- [YYYY-MM-DD] 阶段/场景 — 做法 — 结果(有效|失败) — 适用条件 — 来源项目slug). Daily in-project decisionsare not requiredto be written back. Boundary: method selection facts belong to db03 method cards, personal preferences belong to feedback memory; neither goes into lessons.md.

Write step example (recording one experiment progress)

Five steps just after finishing running the detection baseline (project dairygoat-detect-track): ① Read current state: Read project_card.md to see the current value of experiment_status/next_actions ; ② Modify project card: Edit to change experiment_status to a measured description with specific metrics (e.g. "E1 baseline has been run: YOLOv11@1280, mAP 0.71"), and simultaneously check off/replace the first item of next_actions ; ③ Append decision log: add at the end of decision_log.md - [日期] 决策 — 理由 — 来源；④ Record version: if there is a reproducible tag, add a line to version_history.md and git tag -a；⑤ Cross-session index: If it involves long-term user preferences/project background, write a Light memory file + a MEMORY.md index line. Dates are always absolute dates (today = system currentDate).

At session start

First read the project repository and memory: locate databases/db09-projects/projects/<project_name>/project_card.md，prioritize reading the next_actions fieldConfirm "where we left off and what the next step is"; if necessary, then read the last few entries of decision_log and version_history. After a long session is compressed, recover state from db09/memory rather than short-term memory.

Skip archived projects: when listing/restoring projects, skip projects whose project_card has a non-empty archived: field, and only restore state for active projects; unless the user names that archived project. For completed projects, follow the "Project Archiving Protocol" (see references.md) to add archived: 日期 + write back the final lessons, without deleting the directory or moving the path.

Reuse historical lessons: when starting a new project, or before selecting a method/submission strategybefore, first Grep the top-level db09 lessons.md to search for historically effective practices with similar "stage/scenario" keywords (such as 方案确认/数据准备/投稿); for any reusable hit, note "reused from lesson [date]" when writing decision_log.

Session handoff (proactive handover)

This skill is the executor of the session handoff protocol (for global discipline see CONVENTIONS.md §9). When context is about to run out or a task is wrapping up,proactivelyleave a seed for the user so the next conversation can pick up at zero cost—unlike the passive breakpoint recovery in orchestrator §0 (after-the-fact firefighting), this is seeding in advance.

Four trigger types(better early than late; stage boundaries trigger by default): T1 context level (conversation is very long/has read many files/perceives a compression summary/user says "it's about to give out"), T2 task completion (proactively provide a "next step" prompt when wrapping up), T3 stage switch (before the orchestrator checkpoint passes), T4 user request ("give me a handoff prompt/start a new conversation to continue"). Note: simply "continue writing this section/continue polishing" is single-skill continuation and does not trigger handoff.

Two-piece output(delivered together when triggered): ① handoff card saved to disk .light/handoff/S<NN>-<slug>.md(template templates/handoff_card.md, at the same level as passport.yaml,<NN> incremented by two digits); ② after filling in the specific values according to templates/handoff_prompt.md ,printa Chinese startup prompt; the user copies → opens a new conversation → pastes to continue. For light conversations without a project directory, only print the prompt and do not save a card (known limitation).

Self-contained + self-propagating: each card is independently readable, and the next agent only needs to read the latest card to continue; following the parent_session chain in the card can trace back to any parent conversation. Every successor session must, when wrapping up, create the next card + prompt again, so the protocol does not break its chain. Handoff card ≠ current facts: after taking over, still refresh git/passport/db09/CI evidence according to orchestrator §5.

For complete trigger criteria, disk-saving rules, and the relationship with breakpoint recovery, see references/session_handoff.md. Specific client: Hermes multi-session/compression main-chain recovery (check state.db of parent_session_id/archived/cwd to restore the complete session chain) see references/hermes_session_lineage_recovery.md—the general protocol takes precedence; this is a single-client detail.

Handoff

is the state hub of all skills: the outputs of m01–m17 are all registered here, and the directory of a06 corresponds to it.

For the real endpoints/parameters/known pitfalls of each tool, see references.md。