memory-onboard

/memory-onboard — repo-aware onboarding for memory

This skill is the way to seed a repo with lore. It earns its keep by reading the repo first (README, ADRs, recent commits, deprecation markers, in-flight migrations) so the proposed drafts are specific to this codebase, with source citations — rather than inventing memory or mechanically chunking every bullet in the docs (which produces mostly noise and floods the review queue).

Output: DRAFT records with source citations, plus optional absence markers and boundary edges. Everything lands in memory review for a human to ratify — the skill never promotes its own records.

Hard rules

1. Every lore record this skill produces is a DRAFT. Call suggest_lore (or report_conflict for counter-claims — also drafts), never any approval path. The human reviews with memory review. Exception: record_absence does NOT create a draft — it records a self-expiring "we checked, no policy" marker. Different primitive, different gate (see rule 6).
2. Every draft carries the tag induction so it can be filtered later. Layer topic-specific extras as appropriate (security, conventions, migrations, incident-lessons, invariants, etc.). report_conflict counter-drafts are auto-tagged conflict-report by the server.
3. Cite sources in the body. When a draft comes from a file or commit, include a one-line reference at the top of the body — e.g. Source: README.md L42–55 or Source: commit abc1234 "migrate accounts → organisations". This is the trust signal a reviewer needs.
4. Never put secrets, credentials, personal data, regulated data, or anything that looks like a token into any lore record. If a candidate item contains something like that, skip it and tell the user why.
5. Skip the obvious. "We use TypeScript", "run the tests before committing", and other things a model already knows about a typical codebase belong in CLAUDE.md (or nowhere), not in lore. Aim for non-obvious, high-consequence knowledge.
6. Use record_absence sparingly. If the user explicitly confirms "we don't have a policy on X yet, and that's intentional", that's a legitimate absence marker — call record_absence({ query: "<topic>", reason: "<why no policy>", repo: <repo> }). Don't infer absence from "I didn't find anything in the README"; the user has to confirm it. Markers self-expire (14 days default) so they fade automatically if the team takes a stance later.
7. Use report_conflict when you find a contradiction, not when you find a duplicate. If search_lore returns an existing record and the source-of-truth you just read disagrees with it (e.g. README says "Argon2id", existing lore says "scrypt"), that's a report_conflict moment. If the existing record just covers the same topic without contradicting, leave it alone — possibleConflicts in search results handles benign overlap.