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/changelog-authoring/SKILL.md
+1
View File
@@ -64,6 +64,7 @@ Use `gh pr view <number> --json number,title,body,author,mergedAt` for PR eviden
## VS Code Changelog Rules
- Craft entries only for behavior present in the VS Code extension. Exclude Desktop, Web, Mobile/PWA, and main-app-only UI.
- **Reachability check before every entry.** A change touching shared UI or the VS Code bridge earns a VS Code changelog entry only when the surface is actually mounted from the VS Code entrypoint (`packages/vscode/webview/main.tsx` → `VSCodeApp` → `VSCodeLayout` — which mounts only a subset of shared surfaces; consult the surface map in `packages/vscode/src/DOCUMENTATION.md` when present, trace the mount when not). Shared code that VS Code never mounts is dead there — an entry for it is a false claim users will file bugs about. When in doubt, leave the entry out of the VS Code changelog.
- Do not copy shared/main bullets here unless changed files or code paths show the feature exists in the extension.
- Focus on core UI improvements and VS Code integration.
- Do NOT use "VSCode:" or "VS Code:" prefixes in this file.
.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.