agentsclimarketplace

Verification loop

Skill fengsihao23-eng/shen-hua/skills/verification-loop

A Codex skill pack for long-running project work

Install
npx -y skills add fengsihao23-eng/shen-hua --skill verification-loop

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Shen-Hua verification and repair loop for modified projects. Use after code/config/docs changes that need quality gates, before final readiness claims, when tests/build/lint/typecheck fail, before a PR/commit, or when the user asks Codex to check, verify, test, fix failures, or prove the current work is safe.

SKILL.md

3.3 KB, as published. Nobody here has run it

Verification Loop

Verification Loop runs the strongest practical checks for the current project, fixes failures when in scope, and repeats until the result is known.

Trigger Conditions

Use this skill when:

  • Code, config, scripts, generated assets, or project docs changed.
  • A feature/refactor/repair phase is complete.
  • The user asks to verify, test, lint, build, typecheck, or fix current failures.
  • $project-commander or $handoff-writer needs a readiness statement.

Do Not Trigger

Do not use this skill when:

  • No files changed and the user only asked for conceptual analysis.
  • Running commands would be destructive or require credentials the user has not provided.
  • The project has no executable checks and a lighter file-format review is sufficient; record that limitation instead.

Command Discovery

Before running checks, discover project conventions:

  • JavaScript/TypeScript: inspect package.json scripts and lockfile (pnpm-lock.yaml, package-lock.json, yarn.lock, bun.lockb).
  • Python: inspect pyproject.toml, requirements.txt, tox.ini, noxfile.py, or pytest.ini.
  • Rust/Go/.NET/Java: inspect standard manifests and existing CI config.
  • If AGENTS.md defines verification commands, prefer those.

Verification Phases

Run the applicable phases in this order:

  1. Build or compile check.
  2. Type check.
  3. Lint/static analysis.
  4. Test suite or focused tests.
  5. Security/secrets scan appropriate to the repo.
  6. Diff review for unintended changes.

Skip unavailable phases only with a recorded reason.

Repair Loop

  1. Run the check.
  2. If it fails, read the error carefully and identify the smallest in-scope fix.
  3. Apply the fix without reverting unrelated user changes.
  4. Re-run the failed check.
  5. Continue until checks pass, the issue is out of scope, or a real blocker is reached.

Required .agent/ Updates

Always update:

  • .agent/LOG.md: commands, results, failures, fixes, reruns.
  • .agent/TASKS.md: mark verification tasks and unresolved failures.
  • .agent/HANDOFF.md: final verification status and exact next command if not clean.

Update when relevant:

  • .agent/DECISIONS.md: chosen verification command, skipped gate rationale, accepted residual risk.
  • .agent/REVIEW_CHECKLIST.md: mark verified items.

Other Skills

  • Use $self-reviewer after verification passes or reaches a documented blocker.
  • Return to $project-commander if verification reveals new implementation work.

Subagents

Do not delegate the final verification decision. A tester subagent may run focused checks in parallel only when subagents are available and permitted, but the main agent must inspect the final result.

Output Format

VERIFICATION REPORT
Build:     PASS/FAIL/SKIPPED - details
Types:     PASS/FAIL/SKIPPED - details
Lint:      PASS/FAIL/SKIPPED - details
Tests:     PASS/FAIL/SKIPPED - details
Security:  PASS/FAIL/SKIPPED - details
Diff:      PASS/FAIL/SKIPPED - changed files reviewed
Overall:   READY/NOT READY/BLOCKED
Issues:
1. ...
Next action:

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.