story: validate repo's #213

Open
opened 2026-05-05 04:35:53 +00:00 by despiegk · 0 comments
Owner

Story: HERO Repository Validation Skills

We need a cost-effective way to validate our repositories against clear HERO best-practice requirements.

Instead of using large expensive coding agents for every review, we define small focused validation skills. Each skill checks one area, such as README quality, build/test instructions, security baseline, OpenRPC quality, admin panel conventions, CI/CD, logging, or HeroForge integration.

A hero_validator uses our hero_shrimp agent which uses a repo-skill matrix to know which skills apply to each repository. It runs only the required checks, collects structured findings, and reports them back into HeroForge.

When an issue is found, it should be logged in the correct Forge repository as an issue, with severity, affected file, recommendation, and a link to the validation report.

In a second step, the system may use a bigger model to attempt an automatic fix. This fix must happen on a separate branch and be linked back to the original issue, so it can be reviewed before merge.

Requirements

  • Define reusable validation skills with one clear purpose each.
  • Use a cheap self-hosted model for validation runs.
  • Maintain a matrix that maps repositories to required skills.
  • Produce structured findings in machine-readable and human-readable form.
  • Store validation results in a temporary reporting repo.
  • Create issues in the correct Forge repository when problems are found.
  • Feed validation status and issue lifecycle back into HeroForge.
  • Keep fixing separate from validation.
  • Use a bigger model only for optional fix attempts.
  • Create fixes on branches, never directly on main.
  • Link fix branches back to the original findings/issues.

Deliverables

  • Initial set of validation skills.
  • Repo-to-skill matrix.
  • Validation run format.
  • Reporting repo structure.
  • HeroForge issue creation flow.
  • Finding lifecycle states.
  • Optional auto-fix flow using a bigger model.
  • Branch naming and linking convention for fixes.
# Story: HERO Repository Validation Skills We need a cost-effective way to validate our repositories against clear HERO best-practice requirements. Instead of using large expensive coding agents for every review, we define small focused validation skills. Each skill checks one area, such as README quality, build/test instructions, security baseline, OpenRPC quality, admin panel conventions, CI/CD, logging, or HeroForge integration. A `hero_validator` uses our `hero_shrimp` agent which uses a repo-skill matrix to know which skills apply to each repository. It runs only the required checks, collects structured findings, and reports them back into HeroForge. When an issue is found, it should be logged in the correct Forge repository as an issue, with severity, affected file, recommendation, and a link to the validation report. In a second step, the system may use a bigger model to attempt an automatic fix. This fix must happen on a separate branch and be linked back to the original issue, so it can be reviewed before merge. ## Requirements * Define reusable validation skills with one clear purpose each. * Use a cheap self-hosted model for validation runs. * Maintain a matrix that maps repositories to required skills. * Produce structured findings in machine-readable and human-readable form. * Store validation results in a temporary reporting repo. * Create issues in the correct Forge repository when problems are found. * Feed validation status and issue lifecycle back into HeroForge. * Keep fixing separate from validation. * Use a bigger model only for optional fix attempts. * Create fixes on branches, never directly on main. * Link fix branches back to the original findings/issues. ## Deliverables * Initial set of validation skills. * Repo-to-skill matrix. * Validation run format. * Reporting repo structure. * HeroForge issue creation flow. * Finding lifecycle states. * Optional auto-fix flow using a bigger model. * Branch naming and linking convention for fixes.
despiegk added this to the ACTIVE project 2026-05-05 04:36:07 +00:00
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/home#213
No description provided.