repovine: Skill for Claude Code

repovine-annotations

Maintain the annotation layer through targeted updates, merge/conflict repair, or reviewed batch onboarding.

Skill inputs

The user may ask for:

• default: targeted annotation maintenance for changed/stale nodes
• init or onboard: coverage + estimate + prompt for a first batch
• continue: next batch in the last scope
• domain : scope to one domain
• limit : override the default batch size

Targeted annotation flow

Use this path after concrete code changes, stale annotation signals, or annotation-file conflicts.

1. Refresh first if files changed since the syntax index was built:

refresh_context({})

1. Check annotation health and merge state:

get_annotation_merge_status({})
validate_annotations({})
get_annotation_status({ "view": "coverage" })
get_annotation_status({ "view": "queue", "limit": 10 })

If repovine.annots.json contains conflict markers, call merge_annotations({}) and then validate_annotations({}) before writing notes.

Risk-scope candidate advisory: validate_annotations may report plain/local risks that look like scope:"consumer" or scope:"boundary" candidates, and get_annotation_status({ "view": "risk-scope-candidates" }) pages the review list. A candidate is not proof; inspect the node/source before rewriting. If accepted, rewrite only through write_annotation, preserving the risk text and adding scope. If rejected, leave it local; v1 has no suppression state.

After git merge/rebase: resolve code conflicts first, then merge_annotations({}), git add repovine.annots.json, refresh_context({}), and validate_annotations({}). If merge-review markers remain, compare the ours/theirs assumptions and rewrite the final field via write_annotation.

view: "queue" is one backlog (modules, templates, services, infra, domain roll-ups), not separate queues. Drain order (engine-sorted): (1) content-stale (staleKind: "content"), (2) then propagation-stale (staleKind: "propagation"), (3) then unannotated; within each tier modules and templates before runtime resources, infra and domain roll-ups, and only then bottom-up by dependency depth. Take the top page of view: "queue" — do not run a separate propagation-first pass via derived-review unless the orchestrator explicitly requests propagation-only review. Propagation items: refreshImportBaseline: true unless upstream contract changed. Content-stale: full rewrite. Finish when needsWork: 0. Offsets shift as notes are written.