القائمة
Every "tests pass" / "build green" / "feature works" claim needs the actual command output pasted into the conversation. Bare assertions are worth zero.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | squad-evidence-requirement |
| description | Every "tests pass" / "build green" / "feature works" claim needs the actual command output pasted into the conversation. Bare assertions are worth zero. |
| allowed-tools | ["Bash","Read"] |
| disable-model-invocation | false |
A claim is not done because you are confident it is done. A claim is done when the verification artifact for that claim exists in the conversation, in machine-readable form, that anyone reading later could re-run themselves.
Invoke this skill any time you are about to write the words "tests pass," "build is clean," "this works," "looks good," or any equivalent. Also invoke before running squad done or /done. The pre-flight check for done is whether the evidence pastes are present.
Two artifacts per verification, not one:
squad attest. The binary executes the --command itself, captures stdout+stderr, hashes the result, and writes it under .squad/attestations/. The attestation is the durable record squad done reads to verify the gate.Concrete shape:
squad attest <ITEM-ID> --kind test --command "go test ./..."
squad attest runs the command, captures the output, and stores it. Read the captured output (or re-read it from the printed attestation path) and paste the trailing ok line into chat. One invocation, both artifacts.
Concretely:
ok / PASS / passed summary line. If many packages, summarize as ok: N/M packages, <duration> plus any FAIL block verbatim.<N> errors, <N> warnings line.The next session reading your conversation cannot distinguish "I ran the tests and they passed" from "I think they would pass if I ran them" unless you paste the output. Without the paste, your "done" is unverifiable. Unverifiable "done" rots the team's trust in the backlog: future agents start re-running everything to be sure, which doubles wall-clock per item and defeats the point of the close-out.
The paste is also a forcing function on you. If you cannot paste a green line, you have not actually verified — you have rationalized. Catch yourself in the rationalization before it ships.
squad attest <ITEM-ID> --kind <kind> --command "...". The binary executes the command and writes captured output into the durable ledger.squad attest the durable ledger stays empty and squad done cannot verify the gate. Both artifacts, every time.squad attest --kind <kind> accepts a few standard kinds. Pick the one that matches the run:
--kind test — any unit / integration / e2e command. go test, pytest, vitest, cargo test, npm test. Mandatory for bug / feature / task items; the per-item evidence_required: [test] field gates squad done on at least one attestation of this kind.
--kind review — a reviewer-agent run. Typically captured by reviewer agents themselves per squad-reviewing-as-disprove; the output is the reviewer's findings document or transcript.
--kind manual — manual verification. Browser smoke test, CLI demo, "I clicked through and the modal opened." Write your observations to a file, then attest by pointing --command at a printer that emits them, e.g.:
cat > /tmp/manual-notes.txt <<EOF
clicked the Refine button in the inbox modal — composer opened inline,
typed comments on a passage, submitted; item body redrafted by claude
and SSE pushed inbox_changed within 100ms.
EOF
squad attest <ITEM-ID> --kind manual --command "cat /tmp/manual-notes.txt"
The --command output (your description) is what gets hashed into the ledger. Generic notes like "works as expected" do not count.
The operating loop every session follows — register, tick, pick, work, checkpoint, test, review, commit, close. Use whenever you start or resume work on a squad-managed repo.
Post often, post small, post honestly. The team needs visibility into your non-obvious state — not a change log. Use the typed verbs (thinking / milestone / stuck / fyi / ask) so peers can route attention.
Tick the squad team — surface mentions and file conflicts. Address mentions BEFORE continuing other work.
Before signing off — whether you finished an item or stopped mid-flight — post a 3-bullet summary. Shipped, in flight / queued, surprised by. Three bullets, no ceremony.
Run a structured intake interview with the user — open a session, ask one focused question per turn, draft the bundle, confirm with the user, then commit. Supports green-field (mode=new) and refine-mode (mode=refine) flows.
Evidence-gated close-out for an item. Requires test output paste, code review, and quality-bar pass before squad done runs.