Review and delivery
These skills govern review methodology, GitHub side effects, and human-readable text.
k-review
| Field | Value |
|---|---|
| Use when | reviewing local changes, PRs, or plan/design docs; continuing reviews; addressing review threads |
| Source | exact_k-review |
| Related | Review workflow |
k-review keeps applicability triggers in judging_core.md and loads judging_state.md, judging_change.md, or judging_product.md for matching criteria in final judgment. review_fixes.md covers authorized production before final Verify; review_delivery.md owns delivery. review_post_stage.md explicitly forbids a separate post-review stage: hygiene criteria belong to the integrated final review. Direct reviewer/refuter contracts retain the same applicable criteria and read-only role boundaries.
Final verdict surfaces (PR review, deep review, plan review, and final review/adversarial/audit packets) apply the Check-Coverage Exemption in k-review/references/judging_core.md: exclude a finding class only when a present CI check or a complete local check receipt for the frozen snapshot genuinely covers it, and state CI coverage: covered=[...] -> exempt; in-scope=[...] before findings. pr_common.md owns the PR check-source mechanics. Local iterate-and-fix review (local_changes.md, k-light-review) keeps covered classes in scope because they are fixed in the same pass. This does not certify CI success or permit merging. Delivery and GitHub mechanics consume the existing authorization under SOP §3.8 instead of adding another permission checkpoint.
k-deep-review
| Field | Value |
|---|---|
| Use when | bounded deep-review orchestration, reviewer rostering, findings aggregation |
| Source | exact_k-deep-review |
| Routing | manual |
| Related | Deep-review topology |
The controller now materializes a read-only context pack before fan-out and puts its path plus head_sha in every worker scope packet. Workers load context-pack.md, verify the manifest freshness gate, and report pack_used, pack_stale, or pack_missing instead of re-fetching PR artifacts already present in the pack.
The root resolves scope and PR intent during Understand, produces known authorized fixes before review, and selects final risk questions through reviewer-roster.md. Applicable live UI uses live-ui-validation.md. References supply mechanics and criteria, not a mandatory phase chain. Resume uses the existing stage, snapshot, packet state and evidence pointers. Changed evidence is reported stale; it does not automatically restart intake or review.
Strong artifact review and adversarial challenge answer distinct questions against the same frozen candidate and shared check receipts. Additional specialists, blind fresh-eyes and live UI are selected only for applicable independent risks; shared runtime work stays serialized. Lenses, triggers and checks come from k-review/references/lanes.md; the root pastes the selected lens into the packet so leaves never load the catalog, router or mode files. Findings deduplication is output synthesis, not a findings-auditor/refuter/post-review chain.
Custom memory retains automatic staged recall, root admission and one final verified learning batch through k-ai-kb; no per-controller search ceremony or per-worker scribe. Corrections retain evidence-backed ,agent-memory note capture. Each ready packet returns evidence or a concrete blocker once. Do not relaunch active/completed packets, send sibling messages, revive terminal workers, or treat delivery acknowledgements as progress. Worker conclusions stay provisional until the single final Verify stage consumes raw evidence; no per-return re-verification. Relevant image evidence is viewed in that stage and reused for publication under its separate approval and upload preconditions.
k-light-review
| Field | Value |
|---|---|
| Use when | one focused read-only final judgment of low-risk local changes |
| Source | exact_k-light-review |
| Boundary | select standard review before judging PRs, others' code, risky/stateful changes or required base context; no review-of-review chain |
k-github
| Field | Value |
|---|---|
| Use when | GitHub issue context/targeting and mutations: PRs, issues, comments, reviews, labels, releases, merges, uploads |
| Source | exact_k-github |
| Boundary | owns shared read-only context intake; review judgment stays with k-review, draft-only writing with compose skills |
PR creation and edits are human-visible publication flows. The skill requires full context intake before composition, an explicit publication preflight ledger for title/body/Test Plan/metadata, user approval for invented human-visible text, and read-back comparison after gh pr create or gh pr edit. Review-comment posting preserves review-side UI evidence attachments in the approval/preflight handoff, including md5s, dimensions, and controller image-QA status, while keeping local screenshot paths out of GitHub bodies. Keep PR reviewer fields unset; GitHub handles reviewer assignment automatically. Review submit bodies stay short: acknowledge the review outcome, and when inline comments exist, do not repeat their details. For immediate-team PR authors, clean reviews approve, findings below CRITICAL use comment review, and CRITICAL blockers request changes; outside or unknown-team authors use the normal severity ladder. Requested local-file uploads use the destination repository's web editor because the API cannot create user-attachments assets. The browser flow preserves existing draft text, treats attachment visibility as repository-scoped, and keeps embedding behind the publication gate. Pre-upload QA views every file, checks pairwise-distinct md5s, and rejects missing, empty, or dimensionally implausible images before upload.
k-pr-fix-loop
| Field | Value |
|---|---|
| Use when | working actionable PR review comments through critical assessment, fix, verify, commit, push, PR update, reply, and resolve, with no per-step approval |
| Source | exact_k-pr-fix-loop |
| Routing | manual (disable-model-invocation: true); invoke only on explicit user request for this loop |
| Boundary | a bounded approval packet for this loop's normal effects only (scoped edits, verification, commit, force-with-lease push to the current PR branch, PR body updates, media uploads, review-thread replies/resolves) — does not authorize merging, rebasing, pulling/merging base, unrelated metadata changes, or broad refactors |
Thin wrapper that sequences k-review (references/pr_fix.md in Drain Mode), k-code-quality/k-code-quality-tests, k-git, and k-github.
k-compose-pr
| Field | Value |
|---|---|
| Use when | drafting PR title/body or publication packet before creating or editing a PR |
| Source | exact_k-compose-pr |
| Boundary | draft + publication packet only; no GitHub side effects |
When a draft feeds a GitHub side effect, it carries a PR publication packet outside the PR body so k-github can verify template compliance, screenshot proof status, linked issue intake, Test Plan completeness, metadata status, and unresolved placeholders before publishing. If the effort already has a ,proof receipt, k-compose-pr treats it as completion proof only when its status is allowed, finalized, and sealed intact. A failing, incomplete, or broken ledger is surfaced, never retroactively completed during PR composition; independently verified Test Plan evidence remains usable. The Test Plan is reviewer-runnable: exact commands or manual repro steps with expected and observed results, verified before proposal, not a mirror of changed test files from the diff.
When the change embodies decisions with observable consequences for others (API shape, privilege model, error responses, defaults), the body carries a ## Decisions section — one bullet per decision with the risk if it was the wrong call; internal implementation choices are excluded (decision-log discipline adapted from elastic/plan).
k-compose-issue
| Field | Value |
|---|---|
| Use when | drafting issue title/body or publication packet before creating or editing an issue |
| Source | exact_k-compose-issue |
| Boundary | draft + publication packet only; no GitHub side effects |
When a draft feeds a GitHub issue side effect, it carries an issue publication packet outside the issue body so k-github can verify GitHub issue type, metadata, duplicate checks, parent/sub-issue links, intake, approval, and read-back before publishing.
k-communication
| Field | Value |
|---|---|
| Use when | wording anything another human will read |
| Source | exact_k-communication |
| Boundary | governs wording, not whether publishing is allowed |
| Loaded by | named in SOP §3.8 as a duty before drafting; k-compose-pr, k-compose-issue, k-git (commit messages), k-github, k-slack, k-google-workspace, and k-review load it, including for draft-only output |
| Excludes | session artifacts: SOP references, skill/agent/lane/packet names and IDs, Compatibility impact: lines, Unknown because markers, /tmp/specs paths, ,proof/,agent-memory ledger references, harness/model names, worker reports |
| Owned | Shared external-register rules live directly in the skill entrypoint; the existing-thread procedure remains conditional |
The default message shape is three parts: the point in the first sentence, the doubt when one exists (the assumption you could not verify), and a short collaborative close (wdyt / lmk). That close is the default nicety and replaces longer warmth rather than stacking with it. Budgets are per artifact class (≤40 thread reply, ≤80 comment, ≤200 description), tighter than SOP §5.2's task-class budgets; the terse in-session shape does not carry over, because external readers get direct and polite.
k-present-pr
| Field | Value |
|---|---|
| Use when | building an HTML scrollytelling walkthrough of a PR or local diff |
| Source | exact_k-present-pr |
| Routing | manual |
Read all of authoring.md. Run the bundled scripts/template.py prepare TEMPLATE DRAFT and read the entire editable draft before filling it. render TEMPLATE DRAFT OUTPUT restores the template's exact fixed CSS/JS into a self-contained presentation. Keep its reserved markers unchanged, render again after content edits, and run all static and browser checks on the final output before opening it for the user. The canonical template remains unchanged; the helper replaces only the fixed-code read/copy operation.
Marker validation rejects unknown raw editing comments while allowing HTML-escaped marker text in visible code examples.