repo-evidence-first

Classify repository claims as grounded facts or hypotheses with inspected evidence.

2|Updated May 3, 2026
One-click install
npx skills add https://github.com/Rosetears520/aili-workflows --skill repo-evidence-first
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: repo-evidence-first
Source: https://github.com/Rosetears520/aili-workflows/tree/main/skills/repo-evidence-first
Command: npx skills add https://github.com/Rosetears520/aili-workflows --skill repo-evidence-first

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents confident but unsupported statements about aili-workflows by forcing evidence-backed verification for any non-trivial planning, editing, review, or completion claim.

Core Features & Use Cases

  • Evidence-first claim verification: classifies each project assertion as Grounded Fact, Hypothesis, Open Question, Unverified, or Blocked based on inspected repo anchors.
  • Evidence pack workflow for planning & reviews: creates a structured evidence pack before making claims about “current vs stale,” “authoritative,” “covered by tests,” or “already completed.”
  • Targeted routing to lightweight specialists: dispatches to the appropriate role (code scouting, doc research, web research, test strategy, security review) to obtain compact anchors instead of dumping logs.

Quick Start

Ask the AI to verify a completion claim (e.g., “confirm this change is fixed and passing”) by generating an evidence pack from specific files/lines before stating the outcome.

Frequently Asked Questions about repo-evidence-first

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify code review claims are actually grounded in repository evidence?

Grounding code review claims in repository evidence requires classifying each assertion as a Grounded Fact, Hypothesis, or Unverified state based on inspected file anchors. This structured evidence pack workflow prevents confident but unsupported statements during non-trivial reviews.

What is the best way to check if a completion claim is actually covered by tests?

Checking test coverage for completion claims involves creating a structured evidence pack that explicitly verifies test paths and coverage assertions. This process classifies claims as Grounded Fact or Open Question based on inspected repository anchors before stating the outcome.

How do I detect stale code or conflicting file authority before planning edits?

Detecting stale code and resolving file authority conflicts requires constructing a structured evidence pack that evaluates current versus stale status. It routes to lightweight specialists to obtain compact anchors, ensuring non-trivial planning is backed by grounded repository facts.

Can I use repo evidence packs for security assurance and workflow planning?

Repo evidence packs support security assurance and workflow planning by forcing evidence-backed verification for any non-trivial editing or completion assertion. They dispatch to security review or code scouting roles to obtain compact anchors instead of dumping logs.

What are the limitations of relying on repo evidence status for claim verification?

Repo evidence status verification is limited by dependencies on inspected repository anchors and targeted routing to specialists. Claims remain classified as Blocked or Open Question when authoritative files, test coverage paths, or verification data cannot be explicitly grounded in the repository.

When do I need to generate an evidence pack before stating a task is complete?

Generating an evidence pack is needed before stating task completion whenever non-trivial claims about current versus stale status, authoritative files, or test coverage are made. It forces structured verification through explicit repo evidence status and anchor-based classification.