stow

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

stow

Sweep this conversation for durable knowledge that only exists in chat right now, and file it through the user's explicit instructions, the project's existing local conventions, or the private

.stow-notes.md

fallback in the current directory. The goal is to leave the next session a compact, current operating map, not an accumulating journal: every durable finding lands on disk, and every file this skill touches comes out more accurate, not merely longer. Entries are tiered and decay between passes, and stale material retires to a local archive instead of being deleted. Everything files to a local destination by default; an external system such as an issue tracker is reached only through the explicit-instruction rule in step 3.

扫描当前对话，找出仅存在于聊天记录中的持久知识，并按照用户的明确指令、项目的现有本地约定，或当前目录中私有的

.stow-notes.md

兜底文件进行归档。目标是为下一次会话留下一份紧凑且最新的操作地图，而不是不断累积的日志：每项持久发现都应落盘，而此 skill 触及的每个文件都应变得更准确，而不只是更长。条目分层管理，并在多次处理之间逐步衰减；陈旧材料会退役到本地归档，而不是直接删除。默认将所有内容归档到本地目标；只有依照步骤 3 中的明确指示规则，才会触达 issue tracker 等外部系统。

What it does

功能

Sweep the conversation for uncaptured durable knowledge. Read back over the session and look for:
- User preferences: a working-style, tooling, formatting, or approval preference the user stated in passing rather than through a config file.
- Project facts: build, test, deploy, architecture, or convention facts about the current project that would help anyone (or any agent) working in it later.
- Operational gotchas: a sharp edge, workaround, recurring mistake, or non-obvious cause discovered while working here.
- Standing decisions: a choice made this session that should outlive it, such as an approach settled on, an option ruled out, or a convention agreed to.
- Undone next steps: anything left open or agreed to that has not yet been written down anywhere. Before filing any finding, check whether it already lives authoritatively somewhere - a README, a config file, existing docs, the code itself. If it does, record a one-line pointer to that owner instead of a copy, so the stowed note cannot go stale independently of its source.
Discover the host's existing conventions before deciding where anything goes. Don't assume a destination - look for what's actually there, roughly in this order:
- A project-level memory file, such as
```
CLAUDE.md
```
  ,
```
AGENTS.md
```
  , or an equivalent at the repo root or nearby.
- A user-level (global) memory file the running agent reads across projects, if one exists and is readable.
- A
```
TODO
```
  ,
```
BACKLOG
```
  ,
```
NOTES
```
  , or similarly named plain file already tracked in the project. This step is about local files only; do not scan for or infer an issue tracker here - step 3 owns external routing.
Route each finding using this fixed priority order, local-first.
1. Highest - an explicit instruction wins. If the user has explicitly said, earlier in this conversation or as a standing choice previously recorded in the discovered user-level memory file (see step 4), to use a particular system for this kind of finding, route it there. This is the only path to an external or public system such as an issue tracker, hosted project board, or ticketing system. A configured git host remote, a
```
.github
```
  /
```
.gitlab
```
  folder, or any other signal that a tracker probably exists is never by itself grounds to file anything there - never route externally on inference.
2. Otherwise - the local convention the project or user already has. The discovered project memory file for project facts, operational gotchas, and standing decisions; an existing
```
TODO
```
  /
```
BACKLOG
```
  /
```
NOTES
```
  file for undone next steps; a discovered user-level memory file for user preferences when one happens to be accessible - a bonus if reachable, never an assumption or a requirement. This is the only tier that writes findings into a tracked, shared file or outside the current directory, and only because the user already established that destination.
3. Fallback -
  .stow-notes.md
  in the current directory, for every finding-kind. When no existing convention fits, don't improvise a location or invent an ad hoc filename. In a git worktree, first verify
```
.stow-notes.md
```
  is not already tracked in the index; if it is tracked, do not write private findings there - report that the fallback is blocked until the user chooses a safe destination. Otherwise create or update
```
.stow-notes.md
```
  in the current working directory - never a user-level or home-directory path, so the fallback works even for agents sandboxed to the current directory. Then keep it out of git: add a
```
.stow-notes.md
```
  line to a
```
.gitignore
```
  file in the current directory - an ordinary file at that path, not git's internal exclude mechanism, which can resolve outside the working directory in a linked worktree. Leave staging or committing that
```
.gitignore
```
  line to the user, same as everything else this skill writes. If even the
```
.gitignore
```
  write fails, don't block or error - still write
```
.stow-notes.md
```
  and tell the user to ignore it manually.
When it's genuinely ambiguous between two existing conventions, ask once - then remember the answer. If more than one discovered local convention plausibly fits a finding, ask the user once, plainly, which one they want that kind of note to live in going forward. The same applies when the user gives an explicit instruction to use a tracker or other non-local system going forward rather than just for one item. Once they answer, offer to remember it: with their explicit permission, record a short standing note of that choice in the discovered (or newly agreed) user-level memory file, so the same question doesn't need repeating in this project. Always ask before adding that note - never establish a convention silently. When nothing existing fits at all (not merely ambiguous), that's the step-3 fallback, not a question.
Write only into locations that already exist as a real convention, the step-3 fallback (plus its
.gitignore
line), or a destination the user just approved in step 4. Do not invent new shared files, new folders, or new tracker categories the project doesn't already have. Never store, create, or edit a skill as a destination for a finding: there is no "graduate this to a skill" move, even in a repo whose existing
```
.claude/skills/
```
or
```
skills/
```
directory makes one look like a convention. The offload exit in step 7 does not weaken this: this skill only ever proposes such a move, and the on-demand home is created through the user's own change process, never by this skill's writes. If the fallback is unwritable and the user doesn't want a new convention, say so plainly and leave that finding unfiled rather than fabricate a destination.
Read the destination before writing: inspect-then-update, never blind-append. Before writing any finding, read the destination file's current contents in full - and for a
```
TODO
```
/
```
BACKLOG
```
/
```
NOTES
```
entry, the full existing item, not just its title. Then classify the finding against what is already there: new, duplicate, superseding an existing entry, or evidence that an existing entry is now obsolete. Write the considered replacement that classification implies - a duplicate folds into the entry that already carries it, a superseding finding rewrites the entry it supersedes, and an obsolete entry is refreshed, archived, or replaced in a way that preserves its fact in the same pass - rather than blindly appending a new entry or overwriting the file wholesale. Prefer a one-sentence rewrite of an existing entry over a second entry saying nearly the same thing. A superseded body worth keeping leaves through one of step 7's exits, so it stays recoverable instead of being lost silently in the rewrite. Mark each entry written into a memory file or
```
.stow-notes.md
```
per the tier contract below, but never add tier markers to an existing
```
TODO
```
/
```
BACKLOG
```
/
```
NOTES
```
file. File each undone next step with what it is waiting on, when it is genuinely blocked on something.
Curate every memory file this pass has open, not only the one a finding routes to. Evaluate each dated entry against its tier clock per the tier contract below, refreshing what current evidence re-validates and archiving what stays stale. Archive what is no longer current, including completed chronology, stale versions and paths, transient task state, resolved alternatives, old metrics, and report-sized procedures; merge or remove only superseded claims and duplicates whose facts are preserved elsewhere. Prefer one concise current rule, or a pointer to the authoritative source, over duplicate prose. Never plainly remove a unique current fact: every such exit must archive it with provenance in the recoverable cold tier or relocate it to a live on-demand owner or a consolidation merge that preserves the fact. This is an accuracy discipline, not a length target - a stale entry misleads the next session; a current one earns its place. A
```
.stow-notes.md
```
note has exactly five exits: promotion into a shared, tracked file the user approves; folding into a discovered user-level memory file; archiving to the local, never-loaded archive file; a user-approved move into an on-demand-loaded home (a skill or scoped instruction file), executed through the user's own change process rather than by this skill; or deletion of a duplicate already preserved by a stronger owner - do not invent another.
Finish with an honest safe-to-end verdict and a resume pointer for the next session. Report one action per file this sweep touched or considered:
```
unchanged
```
,
```
added
```
,
```
rewritten
```
,
```
pruned
```
,
```
archived
```
(an entry moved to the local archive), or
```
routed
```
(the finding went to a different owner). Name any proposed moves into an on-demand home still awaiting the user's approval, so they are not mistaken for finished work. Then tell the user, in plain language, what was captured and where, what could not be captured (and why), and whether the conversation is now safe to end or reset - that is, whether every durable finding from this sweep now lives on disk or in an explicitly requested tracker rather than only in this chat. If something could not be captured yet, say so explicitly instead of reporting the session fully safe. If anything landed in
```
.stow-notes.md
```
, say so - note that it is private and confined to this project, and name its promotion exit from step 7 if the user wants it more widely visible. In a git repo, report the ignore protection as it actually happened: either the
```
.gitignore
```
line was added and awaits the user's own commit, or the write failed and the user must ignore
```
.stow-notes.md
```
manually before relying on git to hide it. If the fallback was blocked because
```
.stow-notes.md
```
was already tracked, say that no private fallback was written and the session is not fully safe to reset until the user chooses another destination or accepts that tracked file. If a user preference landed in
```
.stow-notes.md
```
because no user-level memory file was discovered, add one caveat: it now applies to this project only, and the user must copy it into their own global memory file themselves if they want it to follow them across projects. The real payoff of stowing is not this session but the next one: close with a short, copy-pasteable RESUME POINTER naming exactly which files a fresh session should load to pick this back up cold, e.g.
```
To pick this back up in a new session, load: CLAUDE.md (project conventions), .stow-notes.md (private notes, not shared)
```
. List only the files this sweep actually wrote or updated; skip the pointer if nothing was written.

扫描对话中尚未捕获的持久知识。 回看整个会话，寻找：
- 用户偏好：用户随口说明、而非通过配置文件表达的工作方式、工具、格式或审批偏好。
- 项目事实：有关当前项目构建、测试、部署、架构或约定的信息；这些信息会帮助日后在此项目中工作的任何人或 Agent。
- 操作陷阱：工作中发现的棘手边界、变通办法、反复出现的错误或不明显根因。
- 长期决策：本次会话中作出、应在此后继续有效的选择，例如已确定的方案、已排除的选项或已达成一致的约定。
- 未完成的后续事项：任何仍未解决，或已商定但尚未写入任何地方的事项。归档任何发现之前，先检查它是否已有权威存放位置——例如 README、配置文件、现有文档或代码本身。如果有，只记录一行指向该权威位置的指针，不要复制内容，以免归档笔记与来源分别过时。
决定存放位置前，先发现宿主已有的约定。 不要臆测目标位置——按大致顺序查找实际存在的文件：
- 项目级记忆文件，例如仓库根目录或附近位置的
```
CLAUDE.md
```
  、
```
AGENTS.md
```
  或同类文件。
- 运行中的 Agent 会跨项目读取的用户级（全局）记忆文件（如果存在且可读）。
- 项目中已纳入版本控制的
```
TODO
```
  、
```
BACKLOG
```
  、
```
NOTES
```
  或同类普通文件。此步骤只涉及本地文件；不要在这里扫描或推断 issue tracker——外部路由由步骤 3 负责。
按固定的本地优先顺序路由每项发现。
1. 最高优先级——明确指示优先。 如果用户在本对话中更早时刻明确说过，或在已发现的用户级记忆文件（见步骤 4）中记录的长期选择里明确说过，要将此类发现放入特定系统，就路由到那里。这是通往 issue tracker、托管项目看板或 ticketing system 等外部或公开系统的唯一路径。仅因配置了 git 托管 remote、存在
```
.github
```
  /
```
.gitlab
```
  目录或出现其他表明可能存在 issue tracker 的信号，绝不构成归档到那里的依据——绝不根据推断进行外部路由。
2. 否则——遵循项目或用户已有的本地约定。 已发现的项目记忆文件用于项目事实、操作陷阱和长期决策；已有的
```
TODO
```
  /
```
BACKLOG
```
  /
```
NOTES
```
  文件用于未完成的后续事项；如果恰好能够访问已发现的用户级记忆文件，也可用于用户偏好——能访问是额外收获，但绝不能据此假设其存在或将其视为必需。只有当用户已经建立该目标时，这一层级才会把发现写入受版本控制的共享文件或当前目录之外的位置。
3. 兜底——对所有类型的发现均使用当前目录中的
  .stow-notes.md
  。如果没有现有约定适用，不要临时设计位置，也不要自创文件名。在 git worktree 中，先验证
```
.stow-notes.md
```
  是否已在 index 中受跟踪；如果已跟踪，不要把私有发现写入其中——应报告兜底已被阻止，直到用户选择安全目标。否则，在当前工作目录中创建或更新
```
.stow-notes.md
```
  ——绝不使用用户级或主目录路径，以确保此兜底方案在 Agent 被限制于当前目录的沙箱中也能工作。随后让它远离 git：在当前目录的
```
.gitignore
```
  文件中添加一行
```
.stow-notes.md
```
  ——使用该路径下的普通文件，而不要使用 git 的内部 exclude 机制，因为在 linked worktree 中，后者可能会解析到工作目录之外。将暂存或提交该
```
.gitignore
```
  行的工作留给用户，就像处理此 skill 写入的所有其他内容一样。即使写入
```
.gitignore
```
  失败，也不要阻塞或报错——仍应写入
```
.stow-notes.md
```
  ，并告知用户手动忽略它。
当两个已有约定之间确实存在歧义时，只询问一次——然后记住答案。 如果不止一个已发现的本地约定都合理地适合某项发现，就直接询问用户一次，今后这类笔记应放在哪里。如果用户明确指示今后持续使用某个 issue tracker 或其他非本地系统，而非只针对单项内容使用，也适用同样的处理。用户回答后，可主动提出记住该选择：在用户明确许可下，将这项选择的简短长期备注记录到已发现或新近约定的用户级记忆文件，这样在项目中就不必重复询问。添加该备注前始终征得用户同意——绝不能默默建立约定。如果完全没有任何现有约定适用，而不只是存在歧义，则使用步骤 3 的兜底方案，无需询问。
只写入以下位置：已有真实约定的位置、步骤 3 的兜底位置（以及对应的
.gitignore
行），或用户在步骤 4 中刚批准的目标。不要新建项目尚未拥有的共享文件、新目录或新的 issue tracker 分类。绝不能把 skill 用作某项发现的存储、创建或编辑目标：不存在“将其升级为 skill”的操作，即使仓库已有
```
.claude/skills/
```
或
```
skills/
```
目录，看上去像是某种约定，也不例外。步骤 7 中的卸载出口也不改变这一点：此 skill 只会提议此类移动；按需加载的 home 必须由用户自己的变更流程创建，而不能由此 skill 的写入操作创建。如果兜底位置不可写，且用户不想创建新约定，就明确说明，并让该项发现保持未归档状态，不要虚构目标位置。
写入前先读取目标：先检查再更新，绝不盲目追加。 写入任何发现前，完整读取目标文件的当前内容；对于
```
TODO
```
/
```
BACKLOG
```
/
```
NOTES
```
条目，要读取完整现有条目，而不只是标题。然后根据已有内容对该发现分类：新增、重复、取代现有条目，或证明现有条目已经过时。按照分类写入经过审慎处理的替代内容——重复项应并入已有承载该内容的条目；取代性发现应重写其取代的条目；过时条目则应在同一次处理中以保留其事实的方式刷新、归档或替换——不要盲目追加新条目，也不要整体覆盖文件。优先用一句话重写现有条目，而不是新增一条内容近乎相同的条目。如果被取代的正文仍值得保留，应让它通过步骤 7 的某个出口离开，从而保持可恢复，而不是在重写中悄然丢失。按照下方层级约定，为写入记忆文件或
```
.stow-notes.md
```
的每条内容添加标记，但绝不要向现有的
```
TODO
```
/
```
BACKLOG
```
/
```
NOTES
```
文件添加层级标记。记录每项未完成的后续事项时，如果它确实被某项事情阻塞，应写明它在等待什么。
整理本次处理打开的每个记忆文件，而不只是某项发现所路由到的文件。 依据下方层级约定，按层级时钟评估每个带日期的条目：用当前证据重新验证并刷新已重新确认的内容，同时归档仍然陈旧的内容。归档所有不再适用的内容，包括已完成的时序记录、陈旧版本和路径、瞬时任务状态、已解决的备选方案、旧指标和篇幅如报告般的操作流程；仅合并或移除已被取代的主张，以及其事实已在其他位置保留的重复项。相比重复叙述，优先保留一条简洁的当前规则，或指向权威来源的指针。绝不能直接删除任何唯一的当前事实：每个此类退出都必须将该事实连同来源信息归档到可恢复的 cold tier，或迁移到活跃的按需加载 owner，或通过保留该事实的整合合并进行处理。这项
```
.stow-notes.md
```
笔记恰好有五个出口：经用户批准后提升到受版本控制的共享文件；并入已发现的用户级记忆文件；归档到本地且永不由会话加载的归档文件；经用户批准后迁移到按需加载的 home（例如 skill 或 scoped instruction 文件），且迁移须通过用户自己的变更流程执行，而不是由此 skill 写入；或删除已由更强 owner 保留的重复项——不要另造出口。
最后给出诚实的安全结束结论，以及下次会话的恢复指针。 针对本次扫描触及或考虑过的每个文件，报告一种操作：
```
unchanged
```
、
```
added
```
、
```
rewritten
```
、
```
pruned
```
、
```
archived
```
（条目已移入本地归档）或
```
routed
```
（发现已转交给其他 owner）。点明任何仍在等待用户批准、拟迁移到按需加载 home 的内容，以免被误认为已完成。然后用通俗语言告诉用户：已捕获什么以及存放在哪里、无法捕获什么及其原因，以及现在是否可以安全结束或重置对话——也就是说，本次扫描得到的每一项持久知识是否都已落盘，或已按明确要求存入 issue tracker，而非仅存在于本次聊天中。如果仍有内容未能捕获，必须明确说明，不能报告会话已完全安全地结束。如果有内容进入
```
.stow-notes.md
```
，务必说明——指出它是私有内容且仅限于本项目；如果用户希望让它更广泛可见，请点明步骤 7 中对应的提升出口。在 git 仓库中，按实际情况报告 ignore 保护：要么说明已添加
```
.gitignore
```
行并等待用户自行提交，要么说明写入失败，用户必须手动忽略
```
.stow-notes.md
```
，之后才能依赖 git 将其隐藏。如果因
```
.stow-notes.md
```
已被跟踪而使兜底被阻止，应说明未写入任何私有兜底文件，在用户选择其他目标或接受使用受跟踪文件之前，本次会话不能完全安全地重置。如果某项用户偏好因未发现用户级记忆文件而进入
```
.stow-notes.md
```
，还要补充说明：它目前仅适用于本项目；如果用户希望它跨项目生效，必须自行将其复制到自己的全局记忆文件中。 stow 真正的价值不在于本次会话，而在于下一次会话：最后给出一段简短、可直接复制的 RESUME POINTER，准确列出新会话应加载哪些文件，以便从头接续工作，例如：
```
要在新会话中继续，请加载：CLAUDE.md（项目约定）、.stow-notes.md（私有笔记，不共享）
```
。只列出本次扫描实际写入或更新的文件；如果没有写入任何内容，则省略该指针。

Tiered, decaying entries

分层、可衰减的条目

Markers are compact trailing HTML comments, deliberately cheap because marker bytes are part of every file this skill keeps lean:

```

```
- an
```
aging
```
entry; the embedded date is its last-reinforced date.
```

```
- a
```
perishable
```
entry; the embedded date is its last-reinforced date.
```

```
- only in a file whose header pointer opts in to the pass horizon below: either dated marker may carry
```
/N
```
, the number of passes that evaluated the entry without reinforcing it. An absent
```
/N
```
means zero, so an entry you keep exercising costs no counter bytes at all, and a file that has not opted in never writes one.
```

```
- an explicitly
```
pinned
```
entry in a file whose default tier is not
```
pinned
```
.
```

```
- migration-only: an unconfirmed legacy entry that has consumed its one grace cycle, carrying no date because grace is not reinforcement.

markdown

- The staging deploy needs the VPN profile active or the smoke test hangs. <!--a:2026-08-03-->
- CI is red on the flaky auth test until the pinned runner image updates (tracked in TODO). <!--p:2026-07-20-->
- Always run the schema linter before touching migrations. <!--P-->
- The staging seed script must run before the fixture import. <!--a:2026-07-28/6-->

The tier names say what this skill does with an entry:

```
pinned
```
- never decays and is never dropped to shorten a file; it changes only when the user or reality changes it.
```
aging
```
- must re-prove itself: an entry whose age is greater than or equal to 30 days since its last-reinforced date is stale, and a stale entry is re-validated (date refreshed) or archived, never kept by inertia alone.
```
perishable
```
- written to be thrown out: an entry whose age is greater than or equal to 7 days since its last-reinforced date is stale, and its text must name a checkable expiry condition, such as a ticket, a version, or a dated expectation. An entry that cannot name a checkable condition is
```
aging
```
, not
```
perishable
```
.

Rules:

Unless a file's own header pointer names a different default, a user-level memory file defaults to
```
pinned
```
, while a project memory file and
```
.stow-notes.md
```
default to
```
aging
```
.
An entry matching its file's
```
pinned
```
default carries no marker at all; every
```
aging
```
and
```
perishable
```
entry always carries its dated marker, whose letter names the tier, so a clock-carrying entry is never ambiguous with unmarked legacy material.
Marker and pointer bytes are part of the file's cost, so bookkeeping stays minimal by design.
Every governed memory file this skill curates carries at most a one-line header pointer naming this skill as the scheme owner, such as
```

```
, optionally naming that file's default tier when it deviates and the pass horizon when that file opts in, as in
```

```
. The tier semantics, marker spellings, and clocks live only in this skill and are never restated in a file header, which names an option but never its numbers. During one-time migration, add the pointer even to a default-pinned file that contains only unmarked entries, so every governed file names its scheme owner.
Refresh an entry's last-reinforced date only on real evidence from the current session: the fact was used, confirmed, or re-derived. Mere presence in the file is not evidence, and re-reading memory is never reinforcement.
The dates above are the default and only clock, and a file gets exactly them unless its header pointer opts in to the pass horizon. Opt a file in where you stow often enough that the date clock never fires: admitting findings is a per-pass event, so an entry you keep exercising never sits unreinforced for 30 wall-clock days and the file only grows, while a project you stow rarely already passes its date horizon in a single pass and gains nothing. Never add that opt-in on your own initiative; the user chooses it, one file at a time.
While a file is opted in, an
```
aging
```
entry there is stale at whichever comes first - 10 passes that evaluated it without reinforcing it, or 30 days - and a
```
perishable
```
entry at whichever comes first - 3 unreinforced passes, or 7 days. Increment the counter of every dated entry that pass did not reinforce before judging staleness, read a dated marker with no
```
/N
```
as counter zero so nothing needs migrating, and clear the counter only by refreshing the date on real evidence. In a file that is not opted in, never write a counter and never read one that is already there; preserve any existing
```
/N
```
byte-for-byte instead of normalizing or removing it.
Re-confirm a stale
```
perishable
```
entry against its named condition: still open means refresh the date, while resolved, expired, or no longer checkable means archive it now.
Decay is evaluated only when this skill runs; nothing happens between passes, so an infrequently stowed project experiences the clocks at its stow interval.
Stale never means deleted: a stale entry moves to a
```
.stow-archive.md
```
in the source file's own directory, never loaded by any session, and its archive record includes the source filename, tier, reinforcement date when present, and a one-line reason. Include the unreinforced-pass counter only when the pass horizon itself made the entry stale, using the exact reason
```
unreinforced <N>p
```
; omit the counter when the wall-clock horizon or any other reason caused archival, even if the active marker carried one. In a git worktree, verify that this archive path is not already tracked in the index before writing any archived fact there. If it is tracked, do not write to it and report that archival is blocked until the user chooses a safe destination. Otherwise add a
```
.stow-archive.md
```
line to a
```
.gitignore
```
file in the archive's directory, and never write archived facts into a git-tracked file. Recovery is search plus copy back.
Pre-existing unmarked entries are the file's default tier with unknown age, and unknown age is not guilt: an unmarked entry in a default-pinned file is simply pinned and exempt from the aging clock, legacy grace cycle, and archive-by-age, though consolidation still applies.
In a file whose default tier carries a clock, the first pass stamps each unmarked entry it can confirm with its compact dated marker; otherwise it adds
```

```
, which carries no date, to persist one grace cycle without treating presence as reinforcement. On the next pass, current evidence replaces that marker with the normal dated tier marker; without such evidence, archive the entry with a
```
legacy-unvalidated
```
note. The same persisted transition applies to an entry a hand edit later leaves unmarked in a file whose default tier carries a clock.
When an always-loaded memory file has grown past what every session should pay for, this skill may propose - never execute - moving a durable entry that matters only in a nameable situation into an on-demand-loaded home, such as a skill or scoped instruction file the user's agent loads only when that situation arises. The user approves each move, the new home is created through the user's own change process rather than by this skill, and the entry leaves the memory file only once the new home exists. No unique current fact is ever removed or archived during this flow before the on-demand home is live.

标记是紧凑的尾随 HTML 注释；这些标记字节会计入此 skill 保持精简的每个文件的成本，因此其开销刻意很低：

```

```
- 一个
```
aging
```
条目；内嵌日期是其最近一次获得重新验证的日期。
```

```
- 一个
```
perishable
```
条目；内嵌日期是其最近一次获得重新验证的日期。
```

```
- 仅用于文件头指针选择启用下述 pass horizon 的情况：任一日期标记都可携带
```
/N
```
，表示已评估该条目但未重新验证它的处理次数。缺少
```
/N
```
表示零，因此持续被使用的条目完全不增加计数器字节，而未选择启用该机制的文件也永远不会写入计数器。
```

```
- 默认层级不是
```
pinned
```
的文件中，一个显式
```
pinned
```
条目。
```

```
- 仅用于迁移：未确认的旧版条目已用完一次宽限期；由于宽限期不等于重新验证，因此不携带日期。

markdown

- The staging deploy needs the VPN profile active or the smoke test hangs. <!--a:2026-08-03-->
- CI is red on the flaky auth test until the pinned runner image updates (tracked in TODO). <!--p:2026-07-20-->
- Always run the schema linter before touching migrations. <!--P-->
- The staging seed script must run before the fixture import. <!--a:2026-07-28/6-->

层级名称说明此 skill 如何处理条目：

```
pinned
```
- 永不衰减，也绝不为了缩短文件而被丢弃；只有用户或现实情况发生变化时才会改变。
```
aging
```
- 必须重新证明自身：若条目自最近一次获得重新验证之日起，年龄大于或等于 30 天，则该条目为陈旧；陈旧条目必须重新验证（刷新日期）或归档，绝不能仅凭惯性保留。
```
perishable
```
- 写入的目的就是最终丢弃：若条目自最近一次获得重新验证之日起，年龄大于或等于 7 天，则该条目为陈旧；其文本必须指明可检查的到期条件，例如工单、版本或带日期的预期。无法指出可检查条件的条目应归为
```
aging
```
，而不是
```
perishable
```
。

规则：

除非文件自身的头部指针指定了不同默认值，用户级记忆文件默认为
```
pinned
```
，项目记忆文件和
```
.stow-notes.md
```
默认为
```
aging
```
。
与文件
```
pinned
```
默认层级相匹配的条目完全不带标记；每个
```
aging
```
和
```
perishable
```
条目始终携带其日期标记，标记中的字母指明层级，因此带时钟的条目绝不会与未标记的旧内容混淆。
标记和指针字节是文件成本的一部分，因此簿记在设计上保持最小化。
此 skill 整理的每个受管辖记忆文件最多携带一行头部指针，指明此 skill 是该方案的所有者，例如
```

```
；如果文件的默认层级有所不同，或选择启用 pass horizon，也可一并指明，例如
```

```
。层级语义、标记拼写和时钟规则只存在于此 skill 中，绝不在文件头中重复陈述；文件头只命名选项，不重复具体数字。在一次性迁移期间，即使默认层级为
```
pinned
```
的文件只包含未标记条目，也要添加该指针，使每个受管辖文件都能指明方案所有者。
只有在当前会话存在真实证据时，才刷新条目的最近验证日期：该事实被使用、确认或重新推导得出。仅仅存在于文件中并不构成证据，重新读取记忆也绝不算作重新验证。
上述日期是默认且唯一的时钟；除非文件头指针选择启用 pass horizon，否则文件完全采用这些日期。在经常执行 stow、以致日期时钟永远都不会触发的地方，为文件启用该机制：接纳发现是逐次处理的事件，因此持续被使用的条目从不会连续 30 个日历日未得到重新验证，而文件只会增长；对于很少执行 stow 的项目，单次处理时其日期可能已经超过时限，因此启用机制毫无收益。绝不能自行添加该启用项；由用户逐个文件选择。
文件启用该机制期间，其中的
```
aging
```
条目在以下两者中先发生者处变为陈旧：连续 10 次评估但未重新验证，或 30 天；
```
perishable
```
条目则在连续 3 次未重新验证或 7 天中先发生者处变为陈旧。在判断陈旧状态前，为本次处理未重新验证的每个带日期条目递增计数器；读取不带
```
/N
```
的日期标记时视其计数器为零，因此无需迁移任何内容；只有通过当前会话中的真实证据刷新日期时才清除计数器。在未启用该机制的文件中，绝不写入计数器，也绝不读取已有计数器；应逐字节保留任何现有
```
/N
```
，不要规范化或移除它。
针对其指明的条件重新确认陈旧的
```
perishable
```
条目：仍然开放则刷新日期；已经解决、到期或不再可检查则立即归档。
仅在此 skill 运行时评估衰减；两次处理之间不会发生任何变化，因此不常执行 stow 的项目会按其 stow 间隔经历这些时钟。
陈旧绝不等于删除：陈旧条目会移入源文件所在目录中的
```
.stow-archive.md
```
，该文件绝不会被任何会话加载；其归档记录包含源文件名、层级、存在时的最近验证日期，以及一行原因。仅当 pass horizon 本身导致条目陈旧时，才包含未重新验证的处理计数器，并使用准确原因
```
unreinforced <N>p
```
；当 wall-clock horizon 或其他原因导致归档时，省略计数器，即使活动标记中原本携带该计数器。在 git worktree 中，写入任何归档事实前，验证该归档路径尚未在 index 中受跟踪。如果已跟踪，不要写入其中，并报告归档已被阻止，直到用户选择安全目标。否则，在归档文件所在目录的
```
.gitignore
```
文件中添加一行
```
.stow-archive.md
```
，且绝不把归档事实写入受 git 跟踪的文件。恢复方式是搜索并复制回来。
预先存在的未标记条目属于文件的默认层级，且年龄未知；未知年龄并不等于有过错：默认层级为
```
pinned
```
的文件中，未标记条目即为 pinned，不受 aging 时钟、旧版宽限期和按年龄归档的约束，但仍适用整合规则。
在默认层级带时钟的文件中，首次处理时，为能够确认的每个未标记条目添加紧凑的日期标记；否则添加
```

```
，在不把“存在”当作重新验证的前提下，保留一个宽限期。下一次处理时，若有当前证据，则用正常的日期层级标记替换该标记；若没有，则以
```
legacy-unvalidated
```
备注归档该条目。同样规则适用于手工编辑后，在默认层级带时钟的文件中再次变为未标记的条目。
当始终加载的记忆文件增长到超过每次会话应承担的成本时，此 skill 可以提议——但绝不执行——将仅在某种可明确命名的情况下才重要的持久条目迁移到按需加载的 home，例如只有出现该情况时 Agent 才会加载的 skill 或 scoped instruction 文件。每项迁移都由用户批准；新 home 通过用户自己的变更流程创建，而不是由此 skill 创建；只有在新 home 已存在后，该条目才能从记忆文件中移除。在此流程中，任何唯一的当前事实都绝不能先被移除或归档，之后再创建按需加载的 home。

What this skill does not do

此 skill 不做什么

It does not invent a new note-taking system, initialize version control, or stage, commit, or push anything on the user's behalf - every write, including the

.gitignore

line, lands in the working tree for the user to review and commit like any other change. It never files credentials, secrets, or other sensitive material - only knowledge that's safe to keep in plain text wherever it lands. It never files anything to an issue tracker, hosted board, or other external or public system on its own inference - that only ever happens on the user's explicit say-so, per the hard rule in step 3.

它不会发明一套新的笔记系统、初始化版本控制，也不会代表用户暂存、提交或推送任何内容——包括

.gitignore

行在内的每项写入，都只会落到工作树中，等待用户像审查其他改动一样审查并提交。它绝不归档凭据、机密或其他敏感材料——只归档适合以明文保存在任意落盘位置的知识。它绝不根据自行推断向 issue tracker、托管看板或其他外部或公开系统归档内容——根据步骤 3 的硬性规则，只有用户明确同意后才会这样做。