Feat: pinned-SHA attribution footer for pr-review and weekly-report (Phase 6 deferred)

Open
  • Is something wrong?
#10 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
22/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
bash
Domain
tooling

Research direction

Most of the change belongs in rossoctl/automation, not this repo. Start with the Phase 6 spec there and the skill_attribution and resolve_skill_meta functions in github-api.sh, then read pr-review-scanner.sh, pr-review-fixer.sh, pr-review-impact.sh and weekly-report.sh. Done means the review body and the report issue end with the deterministic footer, inline comments stay footer-free, and tests/test-skill-meta.sh covers both consumers. In this repo, the only change is removing the interim footer instruction from the SKILL.md files, then re-vendoring with scripts/vendor-engine.sh.

Written by the indexing model from the issue text.

Description

Follow-up to the Phase 6 attribution design (rossoctl/automation docs/specs/2026-10-05-repoman-phase6-provenance-attribution-design.md, phase issue automation#77).

Background

Phase 6 standardized program footers as Generated by RepoMan <skill>@<sha>, linking rossoctl/agent-skills/blob/<sha>/skills/<skill>/SKILL.md, built by skill_attribution / resolve_skill_meta in github-api.sh. 6a wired it into link-health and dep-bump. The spec deferred pr-review's pinned-SHA footer "until the 6b port makes that code run".

6b shipped in automation#105 (merged 2026-10-08, closed automation#86), but the deferred footer never followed. In skills/repoman/scripts/ on main, pr-review-scanner.sh, pr-review-fixer.sh, pr-review-impact.sh and weekly-report.sh never call skill_attribution.

#9 adds a plain Generated by RepoMan footer to the pr-review and weekly-report SKILL.md instructions. The maintainer accepted it as an interim step. The intended design is a footer the scripts add deterministically, with the skill SHA for provenance.

Where the fix lands

Engine scripts are developed in rossoctl/automation and vendored into skills/repoman/scripts/ by scripts/vendor-engine.sh, so the script changes below go in an automation PR, not straight into this repo. Close this issue with a re-vendor bump (new _vendor.json stamp) once that PR lands. Only the SKILL.md cleanup belongs here.

Scope

  • (automation) pr-review: the review body (and its Slack post) ends with the deterministic skill_attribution github-pr-review footer. Inline review comments stay footer-free.

  • (automation) weekly-report: the report issue (and its Slack post) ends with the deterministic skill_attribution github-weekly-report footer.

  • (automation) Lazy _meta.<skill>.json write in each entry point, following 6a's rules: create-only, write only on success, no sentinel, fall back to blob/main.

  • (repoman) Replace or reword the interim SKILL.md footer instruction from #9 so the agent doesn't add a second footer.

  • (automation) Tests: extend tests/test-skill-meta.sh (or an equivalent) to cover both consumers.

  • (automation) Attribution source is per skill. Every repoman-native skill (everything except github-pr-review) resolves its SHA from rossoctl/repoman (commits?path=skills/<name>) and links rossoctl/repoman/blob/<sha>/skills/<skill>/SKILL.md. Only github-pr-review stays on rossoctl/agent-skills. resolve_skill_meta and skill_attribution write and read _meta.<skill>.json source to match. This covers the existing link-health and dep-bump footers too.

  • (automation) Migration. _meta is create-only and never overwritten, so files already pinned to agent-skills would keep the old source forever. Treat a source mismatch as absent (re-resolve), or delete stale files on upgrade.

  • (repoman) Re-vendor the engine from the merged automation commit.

Out of scope: the dashboard footer, which has no SHA by design (Phase 6 spec).

Assisted-By: Claude Code

Dominant language
Shell
Stars
7
Forks
1
Avg merge
5d 10h
Merged PRs (30d)
2

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rossoctl/repoman

All issues in rossoctl/repoman

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.