dsh-archive-agent-notes
Skill1 starsChanged 13 days agoMITView on GitHub
Use when adding, auditing, pruning, archiving, restoring, or reviewing Agent Notes in deepseek-harness; checks every new note for superseded active records, deletes small UI and purely mechanical records, classifies other implemented notes by future decision value, deletes rejected notes that no longer prevent a tempting fallacy, and applies the frozen archived/{kind} triplet and manifest rules.
10 other projects use a version of this, 7 of them edited.
Adopted by
Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data
Most recently taken up by
- ZeroOnehub/aipm-workbenchword for word, first seen Nov 1, 2026
- See-Sol-Lab/DeepSeekGUIword for word, first seen Oct 18, 2026
- Haifai-AI/baby-whaleedited, first seen Oct 13, 2026
- xinyuquan985-coder/deepseek-harness-neonedited, first seen Sep 26, 2026
- Ydjin1984/DeepSeek_Kibborg_Harnessedited, first seen Sep 25, 2026
- SuperJJ007/papermachineedited, first seen Sep 12, 2026
Used with
Projects with it also use dsh-doc-site-sync and dsh-doc-standards.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
lucaslusSkilldsh-doc-site-sync
Use when publishing, updating, moving, or removing DeepSeek Harness documentation website pages; editing website/docs.ts mappings or navigation; diagnosing a page missing from the VitePress site; fixing projected documentation links; or running the docs:dev, docs:check, and doc-sync workflow after website-content changes.
Also in 5 projects that use this
lucaslusSkilldsh-doc-standards
Use when writing, moving, reviewing, or auditing documentation in the deepseek-harness repo — choosing hierarchy and detail, separating tutorials from references, checking tutorial progression, trimming doc slop, responding to a verify-doc-budgets failure, or requests like "improve the docs", "audit the docs", "where should this be documented", or "this doc is too long".
Also in 5 projects that use this
Other versions10 projects use a version of this.
Word for word · 3
- deepseek-ai/deepseek-harness★ 276k100% same
- See-Sol-Lab/DeepSeekGUI★ 274100% same
- ZeroOnehub/aipm-workbench★ 2100% same
Edited · 7
- SuperJJ007/papermachine★ 5988% same
- xinyuquan985-coder/deepseek-harness-neon★ 1788% same
- Haifai-AI/baby-whale★ 188% same
- lucaslus/dsh-desktop★ 188% same
- SparkElf/deepseek-harness-plus★ 188% same
- SuperMate-Ai/SuperMate-Harness-System★ 188% same
- Ydjin1984/DeepSeek_Kibborg_Harness★ 181% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository25 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .agents/notes/AGENTS.mdAGENTS.md
- .agents/notes/archived/AGENTS.mdAGENTS.md
- .agents/notes/implemented/AGENTS.mdAGENTS.md
- benchmarks/AGENTS.mdAGENTS.md
- docs/AGENTS.mdAGENTS.md
- .github/AGENTS.mdAGENTS.md
- packages/AGENTS.mdAGENTS.md
- scripts/AGENTS.mdAGENTS.md
- snapshots/AGENTS.mdAGENTS.md
- vendor/AGENTS.mdAGENTS.md
- website/AGENTS.mdAGENTS.md
- agent-experienceSkill
- dsh-ci-test-reliabilitySkill
- dsh-client-ui-uxSkill
- dsh-code-reviewSkill
- dsh-docSkill
- dsh-find-simplificationsSkill
- dsh-merging-stacked-prsSkill
- dsh-pre-push-checksSkill
- dsh-prose-standardSkill
- dsh-speed-up-perfSkill
- dsh-translate-docsSkill
- dsh-trim-cot-leakageSkill
- record-browser-gifSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. 11 are common, 0 are distinctive, and 2 are very specific to this project.
11
Common
Most of the 7 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 12
Read the Agent Note rules, the archive instructions, and the applicable active lifecycle instructions before classifying.
- Common: line 25
Proposed — never archive: keep a live proposal active.
- Common: line 27
Rejected — delete: delete the whole triplet when the rejected idea is obsolete, superseded, no longer plausible, or unlikely to prevent …
- Common: line 29
Do not archive toward a quota.
- Common: line 35
Delete implemented notes such as:
- Common: line 40
Keep implemented notes such as:
- Common: line 50
keep folding the compaction package split — 426 words: the temptation to merge the packages remains meaningful.
- Common: line 51
delete streaming workflow progress through tool calls — 972 words: its ACP/UI premise is obsolete.
- Common: line 52
delete dropping ACP terminal metadata — 362 words: the later automation-only ACP decision resolved the question.
- Common: line 59
Search for inbound links from active prose.
- Very specific: line 60
Run pnpm run verify-archived-agent-notes --write.
- Common: line 62
After the triplet is sealed, never edit, move, translate, reformat, or delete it.
- Very specific: line 66
Run the archive verifier's focused test, pnpm run verify-archived-agent-notes, pnpm run doc-sync, pnpm run lint, and git diff --check.
“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Archive DeepSeek Harness Agent Notes
Reduce the active decision corpus without erasing history that can still guide work. Judge every note semantically; word count and age are discovery aids, never archive criteria.
Read the contracts
Read the Agent Note rules, the archive instructions, and the applicable active lifecycle instructions before classifying. Use current code, configuration, package docs, generated catalogs, newer Agent Notes, and inbound links to establish whether a rationale still owns or constrains anything.
Check supersession when adding a note
Before drafting, apply the creation criteria. Every new Agent Note triggers a scoped audit of active notes covering the same decision, mechanism, or rejected alternative. Classify each full or partial supersession while writing the new note: archive qualifying implemented triplets in the same PR, retain and cross-link partial supersessions or independently useful rationale, reject obsolete proposals, and delete rejected notes that no longer prevent a plausible mistake. Apply the Agent Note consolidation rule when the new owner absorbs every unique proposition; do not defer a known match to a later corpus audit.
Classify by future value
Apply these lifecycle-specific outcomes:
- Implemented — delete: delete complete triplets that only describe small UI adjustments or purely mechanical changes, and repair or remove inbound links. Local bug fixes, performance changes, new capabilities, and substantive behavior or ownership decisions do not qualify merely because they are implemented. Apply this criterion before keep/archive classification.
- Implemented — keep active: retain a note when its rationale, alternatives, negative guarantees, durable/wire semantics, ownership boundary, security rule, or reintroduction condition is likely to guide a future change. Classify the decision, not the mechanics of its implementation: a mechanical rename or type extraction can still record lasting naming, compatibility, or ownership rules. Length does not matter.
- Implemented — archive: archive a substantive historical decision when it is complete and unlikely to guide future work, but its historical rationale still warrants preservation. Do not archive records that meet the direct-deletion criterion.
- Proposed — never archive: keep a live proposal active; if it is no longer worth pursuing, reject it with an honest reason and satisfy the rejected lifecycle format.
- Rejected — keep only as a guardrail: retain a rejection only when the losing proposal remains a tempting, meaningful mistake and the note explains why it loses.
- Rejected — delete: delete the whole triplet when the rejected idea is obsolete, superseded, no longer plausible, or unlikely to prevent re-litigation. Repair or delete inbound links.
Do not archive toward a quota. Inspect every note in scope, classify analogous groups under one principle, use best judgment for close cases, and record genuinely borderline decisions for the handoff.
Calibrated examples
These examples set the bar; the word counts demonstrate that size is not the test.
Delete implemented notes such as:
- collapsed sidebar control rail — 533 words: closed, minor UI behavior;
- issue-policy module ownership — completed function relocation and import rewiring with unchanged behavior.
Keep implemented notes such as:
- event-sourced sessions — 248 words: foundational authority and durability boundary;
- single Harness-home resolver — 596 words: cross-product ownership rule;
- project session directories — 628 words: durable storage and identity policy;
- parallel pre-push gates — 400 words: borderline, but still guides gate scheduling and resource tuning;
- dropped image content block — 334 words: keep until multimodal support lands, because it states the coordinated reintroduction condition.
For rejected notes:
- keep folding the compaction package split — 426 words: the temptation to merge the packages remains meaningful;
- delete streaming workflow progress through tool calls — 972 words: its ACP/UI premise is obsolete;
- delete dropping ACP terminal metadata — 362 words: the later automation-only ACP decision resolved the question.
Archive one implemented triplet
- Move the complete
foo.md,foo.zh.md, andfoo.i18n.yamltriplet fromimplemented/<kind>/toarchived/<kind>/;implementedis deliberately absent from the archive path. - Make no body edits. Insert only
Archived: YYYY-MM-DDimmediately belowStatus: implementedin both language files, using the archival date and the same value on both sides. - Re-record the sidecar hashes mechanically for the two metadata-only edits. Do not translate, reformat, update facts, or repair links inside the note. Existing title punctuation, blank-line layout, and language-switcher wording are preserved, not prerequisites for archival.
- Search for inbound links from active prose. Redirect them to current authority, retarget them to the archived path only when the historical snapshot is intentionally cited, or delete them. Never verify or repair links out of the archived note.
- Run
pnpm run verify-archived-agent-notes --write. Its append-only mode first proves every existing seal still matches, then adds only the new triplet hashes. Run the normal verifier afterward.
After the triplet is sealed, never edit, move, translate, reformat, or delete it. Archived notes remain valid inbound-link targets but are historical snapshots, not authority for current behavior.
Validate and report
Run the archive verifier's focused test, pnpm run verify-archived-agent-notes, pnpm run doc-sync, pnpm run lint, and git diff --check; select any additional evidence through dsh-pre-push-checks.
Report active implemented notes kept, implemented notes deleted or archived, rejected notes kept/deleted, proposed notes rejected if any, and every genuinely borderline case with its word count and chosen outcome. Do not claim archived outbound links are valid: the archive verifier intentionally never checks them.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

