cross-validate
Skill47 starsChanged 13 days agoApache-2.0View on GitHub
Cross-validate code changes with independent subagents, execute on-device test witnesses, and generate GitHub issues for discovered follow-ons by default (DOS style). Use after implementing any fix or feature, before reporting completion.
In this repository150 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- llms-full.txtllms.txt
- llms.txtllms.txt
- agent-readinessSkill
- appeal-scoreSkill
- bottleneck-mapSkill
- ci-repairSkill
- claim-repro-scoreSkill
- clear-out-wipSkill
- commit-cleanSkill
- conflation-scoreSkill
- curate-clusterSkill
- debt-cleanSkill
- debt-orchestratorSkill
- disambiguation-scoreSkill
- dojo-rsi-scoreSkill
- dos-dispatch-loopSkill
- dos-dispatchSkill
- dos-next-upSkill
- dos-replanSkill
- dos-witness-claimSkill
- field-borrowSkill
- fleet-waveSkill
- git-subagent-syncSkill
- goalSkill
- guard-rsi-scoreSkill
- harness-creatorSkill
- harness-gardenSkill
- industry-scoreSkill
- issue-orchestratorSkill
- issue-queueSkill
- issue-triageSkill
- lightgap-scoreSkill
- memory-compactSkill
- milestone-scoreSkill
- modularizeSkill
- negframe-scoreSkill
- opencode-waveSkill
- operator-heaviness-scoreSkill
- persona-scoreSkill
- phased-planSkill
- plan-auditSkill
- quality-scoreSkill
- question-loopSkill
- refresh-cachedoc-numbersSkill
- refresh-readmeSkill
- releaseSkill
- resume-watchdog-auditSkill
- run-it-all-nightSkill
- score-2xSkill
- scorecardSkill
- scout-loopSkill
- signal-firstSkill
- skill-lifecycleSkill
- skill-overlapSkill
- skill-scoreSkill
- slop-scoreSkill
- sota-checkSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 5 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Do not report completion without:
- Distinctive: line 35
Ensure no extraneous files are included.
- Very specific: line 66
Only proceed when the status is CLAIM_TEST_GREEN.
- Very specific: line 72
Verify that the commit subject follows Conventional Commits with a recognized (fak <leaf>) trailer and DCO sign-off:
- Distinctive: line 122
Do not leave discovered edge cases, platform gaps, or follow-ons in chat text.
- Distinctive: line 133
Every ticket must state:
- Distinctive: line 143
Check that no residual remains before push:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
cross-validate — adversarial subagent audit, on-device proof & auto-ticketing
DOS discipline: never believe an authoring agent's self-report. A return string claiming "implemented, all tests pass" is narrative, not proof. This skill coordinates independent on-device verification, spawns a dedicated subagent to adversarial-audit the work, and durable-tickets discovered follow-on issues by default.
Load-Bearing Rule
Do not report completion without:
- On-device test execution (
CLAIM_TEST_GREEN) - DOS diff audit (
dos commit-audit HEAD->diff-witnessed) - Independent subagent cross-validation (
CONFIRMED_VALID) - Follow-on issue generation (tickets filed by default for edge cases or soak needs)
Step 0 — Identify Scope & Staged Changes
Inspect the exact changeset to verify what was touched:
git status -s
git diff --stat HEAD~1..HEADEnsure no extraneous files are included. All changes must fall within the lane's declared tree.
For native tuning, apply the AGENTS.md default before expensive execution: independently
review validity and planned cost against existing authorization and budget, binding the review
to exact source/configuration/workload identity, objective, load, and SLO. Check the full
configuration delta and justification for inseparable bundles; attribute results to the bundle
only. Require fresh reference measurements where changed objective or load makes history
incompatible; SLO-only changes may use reassessed compatible history. Candidate changes
invalidate affected review and witnesses only. This review grants neither spend nor security
authority and preserves existing user authorization, budget limits, and security controls.
Step 1 — On-Device Build & Test Verification
Compile without modifying in-tree binaries:
fak-dev buildcheck --vetExecute the affected package tests on-device (routed through WSL on native Windows):
# Whole affected test suite via repo seam:
fak affected
# Or explicit package:
.\test.ps1 ./internal/<changed-pkg>/...Only proceed when the status is CLAIM_TEST_GREEN. An unrun or faulted test is CLAIM_TEST_UNRUN, never a pass.
Step 2 — DOS Commit Audit & Stamp Witness
Verify that the commit subject follows Conventional Commits with a recognized (fak <leaf>) trailer and DCO sign-off:
fak commit --preview
dos commit-audit HEADConfirm the witness level is diff-witnessed. If the audit returns CLAIM_UNWITNESSED or subject-only, the commit makes a claim that the diff does not corroborate — fix the diff or the message before proceeding.
Step 3 — Spawn Concurrent Verification Triad
Spawn a concurrent Verification Triad in a single message turn using multiple task tool calls to independently audit the landed work: cross-validator (adversarial audit) + issue-auditor (edge cases & ticket generation) + tester (regression & matrix execution).
[
{
"tool": "task",
"parameters": {
"subagent_type": "cross-validator",
"description": "Adversarial cross-validation of HEAD",
"prompt": "You are an adversarial verifier auditing recent code changes in commit HEAD.\nDo NOT trust the author's narrative or claims.\n\nYour task:\n1. Run `git show --stat HEAD` and inspect the raw diff with `git show HEAD`.\n2. Verify that edits did not leak outside declared package boundaries.\n3. Check for regressions, concurrency hazards, race conditions, memory leaks, boundary conditions, and nil-pointer risks.\n4. Verify whether the tests actually test the fix/feature or merely pass vacuously.\n\nEmit a structured verdict:\n- VERDICT: CONFIRMED_VALID | DEFECT_DETECTED\n- EVIDENCE: diff inspection + invariant audit\n- DIFF_AUDIT: analysis of edge cases and invariants"
}
},
{
"tool": "task",
"parameters": {
"subagent_type": "issue-auditor",
"description": "Audit edge cases & file tickets",
"prompt": "You are an issue auditor inspecting the changes in commit HEAD.\nYour task:\n1. Uncover unhandled edge cases, boundary conditions, missing platform support (Windows/Linux/Darwin), or soak test needs in the newly added code.\n2. If real follow-ons or gaps exist, draft structured GitHub issue tickets with clear reproduction steps and acceptance criteria.\n\nEmit a structured report:\n- AUDIT_SUMMARY: unhandled edge cases and risk surfaces\n- TICKETS: list of drafted/filed GitHub issues (#N) with Problem/Today/Better because/Witness"
}
},
{
"tool": "task",
"parameters": {
"subagent_type": "tester",
"description": "Regression & matrix test execution",
"prompt": "You are a deterministic tester executing tests for commit HEAD on-device.\nYour task:\n1. Execute on-device package tests: `.\\test.ps1 ./internal/<pkg>/...` (or `go test -v ./internal/<pkg>` and `go vet ./internal/<pkg>`).\n2. Execute regression suites and matrix verification across affected packages.\n3. Observe actual test output and confirm deterministic execution without flaky passes.\n\nEmit a structured verdict:\n- VERDICT: CLAIM_TEST_GREEN | CLAIM_TEST_FAILED\n- EVIDENCE: on-device test command + exact exit code\n- TEST_SUMMARY: passed/failed count and execution duration"
}
}
]Inspect the returned subagent verdicts. If DEFECT_DETECTED or tests fail, address the identified defects and re-verify.
Step 4 — Auto-Ticket Discovered Issues by Default
Do not leave discovered edge cases, platform gaps, or follow-ons in chat text. By default, file durable GitHub tickets for all identified follow-on work:
# Fan out 3..50+ follow-on QA/dogfood/edge-case issues from the spine commit:
fak-dev issue fanout --title "<Feature/Fix Title>" --leaf <leaf> --spine <commit-sha> --json
# Or create targeted follow-on issue via GitHub CLI:
gh issue create --title "<type>(<scope>): <problem>" --body "..."Every ticket must state:
- Problem: the specific unhandled case or gap discovered.
- Today: current behavior or limitation.
- Better because: concrete benefit of addressing it.
- Witness: the command, test, or artifact that will prove the fix.
Step 5 — Final Landing & Receipt
Check that no residual remains before push:
dos review origin/main..HEADConfirm has_residual: false.
Emit the final non-forgeable receipt:
- Commit SHA:
<sha> - Diff Witness:
diff-witnessed - Test Status:
CLAIM_TEST_GREEN - Cross-Validation:
CONFIRMED_VALID - Discovered Issues:
#<issue_numbers>
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

