BuzzbeeSCD/openchamber
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(agents): VS Code reachability gates changelog entries; yulia-ivashko carries maintainer weight

Browse Source 
- changelog-authoring: a VS Code entry requires the surface to be
  mounted from the VS Code entrypoint (consult the surface map in
  packages/vscode/src/DOCUMENTATION.md when present); shared-but-unmounted
  code earns no entry
- triage-prs: yulia-ivashko is a core maintainer with merge rights —
  her review decisions carry maintainer weight in sweeps
This commit is contained in:
Bohdan Triapitsyn
2026-08-28 16:30:55 +03:00
parent 30f635c7ed
commit b5fed6e2e2
2 changed files with 2 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/triage-prs/SKILL.md
+1 -1
View File
@@ -37,7 +37,7 @@ Execute the approved closes/comments with retries and ~1–2s spacing between ca
## Phase 3 — Verdict reviews
**Trusted community reviewers.** Comments and reviews from `patrick-motard` and `mattv8` are strong human signals: during any sweep, collect the PRs/issues they weighed in on, read their assessment, and carry it into the verdict — an approval from them upgrades confidence like a passing verifier; a concern from them is a finding to verify, never to ignore. They write free-form; map their conclusion onto the verdict ladder rather than expecting the format.
**Trusted community reviewers.** `yulia-ivashko` is a core maintainer with merge rights — her review decisions carry maintainer weight (a PR she approved or merged needs no re-verdict; her open questions are the maintainer's questions). Comments and reviews from `patrick-motard` and `mattv8` are strong human signals: during any sweep, collect the PRs/issues they weighed in on, read their assessment, and carry it into the verdict — an approval from them upgrades confidence like a passing verifier; a concern from them is a finding to verify, never to ignore. They write free-form; map their conclusion onto the verdict ladder rather than expecting the format.
The review bot's `review:*` labels are a pre-sort, not a verdict: `review:ready` PRs go first (the bot found no code defects — likely MERGE/MERGE-THEN-FIX), `review:blocked` ones carry a bot comment whose findings the verdict review verifies rather than rediscovers. Bot labels never replace the pr-review pass — the bot cannot judge product fit or maintainability scope.