accenture/mercury-nodejs/harvest-knowledge

harvest-knowledge

⚠️ Tool-managed skill provided by agent-memory (provenance: agent-memory-builtin). Don't edit it

in place — it is overwritten on upgrade. To change behavior: fork it under a new skill name, or

upstream a genuine fix to the agent-memory project (file an issue in its repo, or bring it to the

tool maintainer) for back-port + validation. See SKILLS.md → "Tool-provided (system) skills".

The on-demand, recurring counterpart to the enable-time knowledge harvest (ENABLE.md Step 4b). Enable seeds memory once from the team's docs; this skill keeps it in sync as those docs evolve.

When to use

• The repo's docs have grown or changed since it was enabled — new ADRs, a design spec, decision-log

entries, a roadmap/kanban update.

• To backfill a repo that was enabled before the curious harvest existed (the post-upgrade catch-up).
• A human or agent asks to "harvest knowledge" / "refresh memory from the docs."

On demand only — never part of the per-session ritual, and not tied to enable/upgrade mode.

It is NOT a vendor /init

A vendor /init does a deep code analysis and (re)writes a vendor steering file (CLAUDE.md, .cursorrules, …), usually overwriting it. harvest-knowledge instead:

• reads the team's human-authored knowledge docs (prose — not code),
• distills durable facts into the neutral, shared, committed memory/ layer (every vendor sees it),
• is additive + incremental — it never overwrites curated facts; a conflict becomes a Contradiction

thread, not a silent rewrite,

• is repeatable — run it whenever docs change, not a one-shot bootstrap.

You may borrow /init's analysis muscle, but the output goes to memory/, never a vendor file.

What to do

1. Enumerate, recursively (same net as ENABLE.md Step 4b). Recurse every documentation tree —

docs/, doc/, documentation/, wiki/, rfcs/, adr/, design/, notes/ (all subfolders) — and sweep the repo + module roots for human-authored knowledge markdown: decision logs / DECISIONS*, ADR*, ROADMAP* / TODO* / BACKLOG*, kanban/board files, ARCHITECTURE* / DESIGN*, CONTRIBUTING*, RFC*, GLOSSARY*, onboarding / runbook / postmortem notes. Match .md/.markdown/.mdx/.rst/.txt/.adoc. Exclude (not team prose): node_modules/, vendor/, .venv/venv/, target/, dist/, build/, .git/, generated API reference, minified/vendored files, anything already .gitignored.

1. Scope to what's NEW or CHANGED since the last harvest. Read `last_harvest` from

continuity.md → Project State (the marker this skill stamps in step 7). If present, look only at docs changed since then — git log --since=<date> / git diff --name-only <since>..HEAD over the doc paths. If it's absent (never harvested — or the repo predates this field), treat it as a full first pass. Either way, budget with disclosure: cap the read (prioritize roots → docs/ → recently-modified); if the budget is hit, record a - [ ] (knowledge-harvest) Open Thread listing what's left, so nothing vanishes silently. (last_harvest only scopes the read — the step-4 check-existing-first guard is what actually prevents duplicates, so a re-scan is always safe.)

1. Distill — don't transcribe — into memory, additively:

• conventions / architecture decisions / hard constraints → memory/instructions.md (and seed

Architectural Invariants from explicit "must / never" rules);

• current goals / roadmap / in-flight work / decision-log open items → Open Threads; the aspiration →

the Current-state context of memory/vision.md (never fabricate the target);

• newcomer-facing knowledge → candidate smoke-test questions.
• Map, don't mirror: link the canonical doc and capture only the enduring fact — never duplicate a

living doc into memory.

1. Check each candidate against existing facts first (DECAY.md §10) so a re-run doesn't duplicate.

A harvested fact that contradicts an existing one → raise a - [ ] Contradiction: … Open Thread (never-pick-a-winner); a genuine replacement → supersede the old fact (DECAY.md §9). Never silently overwrite curated memory.

1. Human-gated. Summarize what you folded in, what you superseded/flagged, and what you skipped for

budget — let the human review before it's treated as settled.

1. Record it. A harvest is a memory-relevant event → write a session log with a ## Memory References

section listing the fact ids you created / changed (it stays inside the normal after-session ritual).

1. Stamp `last_harvest` in continuity.md → Project State: `last_harvest: <today> | through <this

session-file> (create the field if absent — it sits with last_review / last_invariant_check). This is what step 2 reads next time, so each run scopes incrementally. The harvest **owns** last_harvest, the way the review owns last_review. Even a **no-op** run (nothing new to fold) stamps it — that records "docs were checked through here." Write it safely (REVIEW.md` → Safety: never truncate-before-read).

Notes

• No-code, agent-run — there is no script; the agent reads the docs and writes memory

(no-build-step-agent-run). The runtime is the agent, on any vendor.

• Additive + safe-to-repeat — running it again should enrich, not duplicate (step 4) and never destroy

curated memory. When scripting any memory edit, follow REVIEW.md → Safety (never truncate-before-read).

• Pairs with the enable-time harvest (ENABLE.md Step 4b): identical rules, different trigger —

one-shot at enable vs. recurring on demand here.