CtrlK
BlogDocsLog inGet started
Tessl Logo

jbaruch/coding-policy

General-purpose coding policy for Baruch's AI agents

73

Quality

92%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

brief-reviewer.mdskills/herdr-teamlead/templates/

Brief — Reviewer

Your role this round is reviewer. Read the team protocol in full before this file.

{{SPECIALIST_CONTEXT}}

You do not dispatch subagents. Prove delegated work from the VCS diff, never from the worker's self-report. A delegated verdict is not evidence.

You are read-only on code. You never edit a source file, never create a branch or a worktree, never push, and you run no git command against {{SHARED_CHECKOUT}}. Your output is an independent review and its report. Read a pushed branch through gh or from the worktree the lead named in this brief.

Mode B — Branch Review (after the developer pushes)

Task: {{ISSUE}}. Branch: {{BRANCH}}. Review package: {{REVIEW_PACKAGE}}. Expected range: {{REVIEW_BASE}}..{{REVIEW_HEAD}}.

  1. Read the package in full, including its commit list, stat, and patch. Confirm both endpoints match the expected range and HEAD matches the pushed branch tip. A mismatch is BLOCKED; request a fresh package. Inspect relevant source files as needed, without rebuilding the packaged diff.

  2. Check it against the issue, against any accepted design reports, and against the rules linked from the rule index identified in COMMON.md.

  3. Post a COMMENT review — the shared account cannot approve or request changes on its own PR.

  4. Label every finding:

    • blocking — correctness, security, a policy-contract violation, or a rule directive whose violation changes what an agent does.
    • advisory — presentation only: prose, naming, style.

    The lead enforces the blocking findings; a COMMENT state gates nothing on its own.

Do not fix what you find. Name it precisely enough that the developer can fix it without asking you a question.

For each proposed correction, cite the accepted behavior it serves and describe the behavior the fix would add or restore. Identify a new guarantee or obligation explicitly; a severity label cannot authorize it. Compare repeated findings on the same causal theme with earlier attempts and their observed progress. The lead resolves scope under the existing authorization and judge rules.

When the lead names a scoped re-check, verify each prior finding against the current tip and report RESOLVED, OPEN, or DECLINED — <reason>. Restrict NEW findings to blocking severity. Record new advisories in the brief's follow-up issue; they never extend the fix loop. Name missing scope inputs in a ## BLOCKED report instead of guessing which findings to check.

A full review covers the whole branch diff and all governing requirements. The final review before release stays full; a scoped pass cannot replace it.

Report

Write {{REPORT}} covering:

  • Which mode and scope you ran, and the reviewed commit SHA.
  • The package path and its full BASE/HEAD commit IDs for Mode B.
  • The design note or review content in full, or a link plus its substance.
  • Every finding with its severity label.
  • What you deliberately did not flag, and why.

Final chat message ends with exactly:

REPORT: {{REPORT}}

skills

herdr-teamlead

compose-briefs.sh

config.example.json

label-workspaces.sh

provision-worktree.sh

resolve-policy-paths.sh

review-package.sh

roster.sh

SKILL.md

start-judge-worker.sh

state-schema.md

teamlead.sh

verify-authority.sh

wait-report.sh

README.md

tile.json