sync-feedback-loop

Imported from basskibo/bank-memo-tool- (credit-memo-agent/.claude/skills/sync-feedback-loop/SKILL.md). Install upstream with npx skills add basskibo/bank-memo-tool- --skill sync-feedback-loop. Copyright stays with the author.

name: sync-feedback-loop description: Sync this project with the feedback-loop template repo — pull core/skeleton updates down, or push a locally-learned convention improvement upstream. Use when asked to update the feedback loop / docs conventions, or when a triage/docs lesson here should benefit other projects.

Sync with the feedback-loop template

The template repo (URL in .feedback-loop-version at this project's root) is the single source of truth for the conventions. Two directions; ask which (or infer from the request).

Shared ground rules

• Core files are identical everywhere. Any diff between a local core file and the template's is either an un-pulled update (pull it) or illegal local drift (resolve it by moving the change upstream or reverting it — never by leaving a fork).
• Adapter sections are project-owned and never pushed upstream as content — but a new kind of adapter fact worth prompting for belongs upstream as a placeholder description.
• Ledger rows, actual ADRs/notes/references, and helper scripts are project content: never synced in either direction.

Direction A: pull template updates down

1. Read .feedback-loop-version; clone/locate the template repo; read its CHANGELOG.md entries since that version. If none: report "up to date", done.
2. For each changed core file: copy it over the local copy verbatim.
3. For each changed skeleton: copy the new version, then re-apply this project's <!-- ADAPTER --> sections from the old local copy (they are delimited exactly so this is mechanical). If an adapter section was added/renamed upstream, fill it by asking the user or reading project infra — flag it in the report.
4. diff every synced core file against the template to confirm identity; bump .feedback-loop-version.
5. Report: which files changed, why (from the changelog), and any new adapter sections that needed answers.

Direction B: push a lesson upstream

Use when this project learned something that changes the conventions — a new evidence rule a triage should always apply, a new report section that earned its place, a new ledger status, a sharper decision-tree question. Project-specific facts (a particular bug, a particular tool) stay local.

1. Generalize first. Strip project names, paths, tools; keep the transferable rule and, in one clause, the incident that taught it (dateless project-agnostic phrasing, or "seen in the wild in an adopting project").
2. Edit the template repo's core/skeleton file; add a CHANGELOG.md entry (bump the minor version) saying what changed and why.
3. Immediately run Direction A in this project so it consumes its own contribution — the local copy must end identical to the new template version.
4. Report: the upstream diff, the new version, and a reminder that other adopting projects sync on their next opportunity.

Rules

• Never resolve a core-file conflict by editing the local copy alone.
• Never push project content (rows, notes, scripts, adapter values) upstream.
• Every upstream change gets a changelog entry — the changelog is what makes other projects' pulls cheap.
• Keep upstream edits small and sharp; the template rots through bloat, not through gaps.