Keep the internal review loop out of pull requests, and work off every posted review point

[LarsLaskowski]

Pull Request

📖 Description

Two changes to this repository's own skill definitions, both about what
happens around a pull request rather than inside the Go code.

1. The internal review loop no longer leaks into the PR. create-pr and
fix-issue used to instruct the session to record how many internal review
passes it ran and which commits resolved their findings in the PR's Reviewer
Notes, and to park non-blocking findings in Next Steps. That filled pull
requests with the history of how a change was produced, which no reviewer
needs — the value of that loop is already in the diff. A new section, The
loop stays invisible, replaces it: the PR documents the finished state
(affected components, touched guarantees, smoke test) and never the passes
that produced it. The section is scoped explicitly to the pre-push loop;
public review on an open PR stays public.

2. Every point posted as a review comment gets resolved in that same PR.
The old rule sent non-blocking findings to Next Steps where they were not
chased, and a finding could be deferred to "the next change that touches this
file" — a change that is not scheduled, and that happens long after the
session holding the context is gone. A posted point now has exactly three
outcomes, all reached while the PR is open: fixed, declined with a reason, or
split into an issue created right away and linked from the reply, then
the thread is resolved. A promised follow-up issue that nobody creates is not
an outcome.

The round caps are unchanged (three internal passes, two rounds on GitHub).
What changed is what they cap: how often a change is re-reviewed, not how
many findings get worked off.

Separately, at the repository owner's request, the bullets telling the
session to strip Co-Authored-By / session-link trailers from commits and PR
bodies are removed from both the .claude and the .agents skill trees.

No Go code is touched; no runtime behavior changes.

🎫 Issues

None — this came from a direct request, not a filed issue.

👩‍💻 Reviewer Notes

Components touched — documentation and agent configuration only:

• .claude/skills/create-pr/SKILL.md — new sections The loop stays
  invisible and Every posted review point gets resolved in this PR; step 7
  no longer asks for review-pass bookkeeping in Reviewer Notes; the loop gains
  a step 5 covering fixes made after the final pass.
• .claude/skills/fix-issue/SKILL.md — the same two sections; steps 7 and 8
  rewritten accordingly.
• .claude/skills/review-pr/SKILL.md — Answering findings on your own PR
  now spells out the three outcomes; the round-cap bullets say they cap
  rounds, not findings.
• .claude/agents/pimonitor-reviewer.md — the NON-BLOCKING severity
  description no longer says such a finding "does not gate the pull request",
  which would have contradicted the new rule.
• CLAUDE.md — a short summary of both rules, pointing at the skills.
• .agents/skills/{create-pr,fix-issue}/SKILL.md — attribution bullets
  removed.

Guarantees this had to preserve: none of the Go-side ones are in play —
no /api/v1/... response shape, collector, config key, route or packaging
file is touched, and the unprivileged/privileged service split is untouched.
The guarantee that was at risk is internal consistency between the four
skill/agent documents, since an agent follows several of them at once.

Where to look first: the interaction between The loop stays invisible
and Every posted review point gets resolved in this PR in create-pr. The
first is deliberately scoped to the pre-push loop; if it were read as covering
comments on an open PR, it would forbid the Fixed in <sha> replies and the
posted verdict line that review-pr requires. The opening paragraph of each
section is what keeps those two apart — worth reading against
review-pr/SKILL.md lines 30-40 and 61-82.

Smoke test (no Pi hardware needed — these are agent instructions):

1. /create-pr on a branch with a small change: the resulting PR body should
   describe the change and its smoke test, and contain no mention of review
   passes, findings, verdicts or the reviewer subagent.
2. Post a non-blocking review comment on that PR and ask the session to
   address it: it should fix it, decline it with a reason, or create and link
   an issue — and resolve the thread — rather than adding it to Next Steps.
3. /fix-issue on any open issue: same expectation for the PR it opens.

📑 Test Plan

The diff is Markdown only and changes no Go code, so it adds no Go tests —
there is no code path to cover. The repository's verification was run anyway
to confirm nothing broke:

• go build ./... — clean
• go vet ./... — clean
• gofmt -l . — no output
• go test ./... -race -cover — all six packages pass (alert 92.8%,
  collector 92.0%, config 96.4%, httpapi 98.5%, web 84.2%, cmd 7.3%)
• golangci-lint run — could not run in this environment: the installed
  binary is built with Go 1.25 while the project targets 1.26.7, so it exits
  on config load. Pre-existing and unrelated to this diff; CI will cover it.

Beyond that, the documents were checked against each other and against
.github/pull_request_template.md: every section name they reference exists,
the three round-cap statements agree across the three skills, and the old
"non-blocking goes to Next Steps and is not chased" rule survives nowhere in
the repository.

✅ Checklist

General

• I have added/updated tests for my changes (go test ./... -race -cover passes locally).
  Not applicable — Markdown-only change with no Go code path to test. The suite passes locally.
• go vet ./... and golangci-lint run are clean.
  go vet is clean; golangci-lint cannot run here (Go-version mismatch, see Test Plan).
• I have tested my changes.
• I have read the CONTRIBUTING documentation and followed the project's code style guidelines.
• I have updated ARCHITECTURE.md if this changes a documented design decision.
  Not applicable — no documented design decision changes.

⏭ Next Steps

• The .agents/skills/ tree is a leaner variant that never received the
  review-loop sections at all — it has no internal loop, no reviewer agent,
  and now differs from .claude/skills/ in more than wording. Deciding
  whether that tree should track the .claude one or stay deliberately
  minimal is worth a separate look; this PR only kept the attribution bullets
  from diverging.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud