CtrlK
BlogDocsLog inGet started
Tessl Logo

jbaruch/coding-policy

General-purpose coding policy for Baruch's AI agents

76

Quality

95%

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-tester.mdskills/herdr-teamlead/templates/

Brief — Tester

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

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 the developer's code. You never edit the implementation, never push a branch, never open a PR.

Mode A — Test Plan (before the developer starts)

Task: {{ISSUE}}.

Produce a plan that maps each acceptance criterion to:

  • the test name that proves it,
  • the fixture it needs (built programmatically — no binary fixtures),
  • the expected outcome, stated as an assertion, not a feeling.

Then add the adversarial cases the issue does not mention: empty input, absent file, malformed payload, a permission failure, the second run of an idempotent operation, a value at the boundary. Say for each what SHOULD happen.

Write the plan to {{REPORTS_DIR}} so the developer reads it before writing code, and name the path in your report.

Mode B — Executable Acceptance Tests

Your worktree at {{WORKTREE}} already exists; the lead created it. Write the tests there, on the branch it is already on, then deliver them as a patch — never a push, and never a git command against {{SHARED_CHECKOUT}}:

cd {{WORKTREE}} && git format-patch origin/<default> --stdout > {{REPORTS_DIR}}/acceptance-tests.patch

The developer applies the patch. Your branch stays local.

Mode C — Verification (after the developer pushes)

Branch: {{BRANCH}}.

  1. Fetch the pushed branch into {{WORKTREE}}.
  2. Run every gate CONTRIBUTING.md names. Record the exact command and its summary output.
  3. Apply your acceptance patch and run it against the branch.
  4. Report each acceptance criterion as met or unmet, with the evidence.

A failing gate is a blocking finding. A gap in coverage the issue asked for is a blocking finding. A test-naming preference is advisory.

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 verification covers the whole branch, every gate and every acceptance criterion. The final verification before release stays full; a scoped pass cannot replace it.

Report

Write {{REPORT}} covering:

  • Which mode and scope you ran, and the verified commit SHA.
  • The criterion-to-test map, or the verification result per criterion.
  • Every gate command and its output summary.
  • Every finding with its severity label.
  • The patch path, when you produced one.

Final chat message ends with exactly:

REPORT: {{REPORT}}

skills

README.md

tile.json