SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillshello-verify

hello-verify

Coding & development

View repository

Updated 10-15 22:12

About this skill

Before claiming completion, there must be verification evidence. .helloagents/ In this skill, uniformly understand it as the project-level storage path:.ralph-review.json、.ralph-visual.json、.ralph-closeout.json and other delivery evidence remain project-local; if project_store_mode=repo-shared，verify.yaml, the solution package, and DESIGN.md are resolved according to the project knowledge/solution directory already injected in the current context.

Iron Rules

Without running verification commands = you cannot say "complete", "passed", or "fixed". Without seeing verification output = you cannot claim results.

Verification Loop

Verification is not a one-time operation, but a loop until it passes:

任务完成
  ↓
运行验证命令（lint/test/build/typecheck）
  ↓
全部通过？
  ├─ 是 → 收集已激活技能的交付检查清单 → 逐项确认 → 报告完成
  └─ 否 → 反思 → 修复 → 重新运行验证（回到循环开头）

This loop has no upper limit. If verification fails, fix it; after fixing, verify again, until everything passes. It is not allowed to report completion while verification is failing or ask the user whether to skip it.

Reflection (must be performed when verification fails)

After verification fails, it is forbidden to skip reflection and directly modify code. You must first answer:

  1. What is the root cause of the failure?
  2. What did the previous implementation miss?
  3. What is the fix? Will it introduce new problems?

Circuit Breaker

3 or more consecutive verification failures → activate hello-debug's stuck escalation mechanism.

Progress Detection

When claiming task completion, there must be actual file changes. If git diff is empty (no file changes at all), you cannot claim to have completed a task that produces files.

Atomicity Self-Check

Check the scope of changes before committing:

  • If a single change involves >5 files → pause and re-evaluate whether it should be split into multiple independent changes
  • Describe the change in one sentence; if you need to use "and" to connect unrelated operations → split into multiple commits
  • Each commit should be an atomic operation: either everything is meaningful, or everything is rolled back

Code Size Check

Files involved in the change must comply with the size control rules in the coding principles of the currently loaded bootstrap:

  • File/class >300 lines → evaluate whether splitting is needed
  • File/class >400 lines → must be split by responsibility (exceptions: generated code, large test fixtures, migration scripts, protocol constant tables)
  • Function/method >40 lines → evaluate whether splitting is needed
  • Function/method >60 lines → must be split

Regression Guard

Optimization or new features must not break existing tests:

  • After modifying code, first run existing tests to confirm there is no regression
  • If new code improves metrics but existing tests fail → fix the regression (at most 2 attempts), do not modify existing tests
  • Existing tests are the bottom line; it cannot be lowered for the sake of new features

Sources of Verification Commands

  • Logic .helloagents/verify.yaml commands in (priority;project_store_mode=repo-shared when resolved according to the shared knowledge directory)
  • lint/test/typecheck scripts in package.json
  • ruff/mypy/pytest in pyproject.toml

Delivery Checklist Gatekeeping

After all verification commands pass, you still need: These markers are only used for delivery checklists, acceptance records, and verification results, not for ordinary explanations, solution explanations, or progress reports.

  1. Collect the delivery checklists of all activated hello-* skills
  2. Confirm each check item one by one, mark [√] and attach evidence (e.g.:src/api.ts:42 parameterized queries are used)
  3. Mark non-applicable items with [-] and explain the reason
  4. There are failing items → fix → rerun the verification loop
  5. If a solution package currently exists and you are preparing for final wrap-up, prioritize calling scripts/closeout-state.mjs write to write .helloagents/.ralph-closeout.json, recording the two conclusions of requirementsCoverage and deliveryChecklist ; both must include status（PASS / BLOCKED) and summary
  6. If the current solution package requires review-first, you must first confirm that .helloagents/.ralph-review.json has passed and scripts/review-state.mjs write is written as the latest structured evidence; do not treat review natural-language messages directly as delivery evidence
  7. If contract.json contains ui.visualValidation.required=true, you must confirm that .helloagents/.ralph-visual.json has passed and scripts/visual-state.mjs write is written as the latest structured evidence; if there is no visual acceptance evidence, this round must not be regarded as UI-deliverable
  8. When preparing to report completion with this round's final wrap-up message, first call scripts/turn-state.mjs write to write kind=complete、role=main; if you stop because of a blocking determination awaiting input or because of missing preconditions, write kind=waiting or kind=blocked, and also write reasonCategory and reason, do not let the runtime guess the status from natural-language messages

Requirements traceability verification

If there is a solution package (requirements.md), after completion you must cross-check:

  1. Read the requirements in requirements.md one by one (core goals, functional boundaries, quality requirements)
  2. Confirm that each requirement has a corresponding task implementation and has not been silently dropped
  3. Confirm that the content listed in the non-goals section has indeed not been implemented (to prevent scope creep)
  4. If "completion criteria" are defined in tasks.md, confirm item by item that each task's completion criteria actually hold; do not treat them as complete merely because the code exists or the command passes
  5. If contract.jsonexists, confirm item by item that its verifyModeand the boundaries of concern for reviewer / tester have all been covered by this round's verification
  6. If contract.json contains advisor.required=true or ui.styleAdvisor.required=true, additionally confirm that .helloagents/.ralph-advisor.json already exists and the conclusion is clean; if there is no advisor evidence, this round must not be regarded as deliverable
  7. If contract.json contains ui.visualValidation.required=true, additionally confirm that .helloagents/.ralph-visual.json already exists, covers the required key screens / states, and the conclusion is PASS; if there is no visual acceptance evidence, this round must not be regarded as UI-deliverable
  8. Found an omission → supplement the implementation → re-verify

Goal drift check

During verification you must distinguish between true goals and proxy metrics:

  • True goal: the problem the user actually wants solved (correct functionality, satisfactory experience, requirements met)
  • Proxy metrics: tests pass, lint is clean, type checking passes, diff is tidy

All proxy metrics passing ≠ the true goal being achieved. During verification you must answer:

  1. What is the user's true goal?
  2. Does the code actually achieve this goal? (not "the tests say it passes", but "the functionality really works")
  3. Is there a situation where tests pass but the functionality actually does not work? (e.g.: the tests mock key dependencies, the tests only verify the happy path)

Reverse goal verification

Do not start from "is the task complete?", but rather derive in reverse from the goal:

  1. Define the phase goal clearly (what result does the user want?)
  2. Reverse engineer: to achieve this goal, which conditions must be true?
  3. Verify each condition one by one, using the four-level verification depth

Four-level verification depth

Every key output must pass the four-level check:

  1. Existence — the file/function/component actually exists
  2. Real — contains a real implementation (not a stub, TODO, placeholder, or empty function)
  3. Connected — imported/called/used by other code (not isolated dead code)
  4. Data flow — real data flows through it (the API returns real data, the UI renders real content, events actually fire)

Failing any level → treat as incomplete and must be fixed.

Danger signals

The following thoughts mean you are rationalizing skipping verification:

  • "It should be fine now" → run verification
  • "I am very confident" → confidence ≠ evidence
  • "The linter passed" → linter ≠ test ≠ build
  • "Changing the code should have fixed it" → run verification to confirm
  • "Just skip it this once" → no exceptions
  • "Ask the user whether to skip" → not allowed, must fix
  • "Write it first and test later" → untested code is a liability, not an asset
  • "I already tested it manually" → manual testing has no record, is not repeatable, and cannot be regressed
  • "It is too simple to need testing" → simple code still fails in complex systems
  • "This time is an exception" → every exception becomes a precedent
  • "The user did not ask for testing" → quality is the baseline, not an option

Five-step evidence chain (must be completed before claiming completion each time)

  1. Identify — determine which command can prove your claim
  2. Run — execute that command completely
  3. Read — review the complete output and exit code
  4. Verify — confirm the output actually supports your claim
  5. Claim — report the result with evidence