← Browse

@crocoder-dev/sce-validation

A

Use when user wants to Run final plan validation and cleanup with evidence capture.

skillclaude

Install

agr install @crocoder-dev/sce-validation --target claude

Writes 1 file into .claude/skills/, pinned to git-5b647df3.

  • .claude/skills/sce-validation/SKILL.md

Document


name: sce-validation description: Use when user wants to Run final plan validation and cleanup with evidence capture.

When to use

  • Use for the plan's final validation task after implementation is complete.
  • Triggered by requests like "validate the plan", "run final checks", "confirm everything passes", "wrap up the task", or "sign off on this change".

Validation checklist

  1. Run full test suite - discover and run the project's primary test command (e.g., pytest, npm test, go test ./..., cargo test, make test). Check package.json, Makefile, pyproject.toml, or CI config files to find the right command.
  2. Run lint/format checks - discover and run the project's lint and format tools (e.g., eslint, ruff, golangci-lint, cargo clippy, make lint). Check project config files such as .eslintrc, pyproject.toml, or .golangci.yml.
  3. Remove temporary scaffolding - delete any debug code, temporary files, or intermediate artifacts introduced during the change.
  4. Verify context reflects final implemented behavior - confirm that plan context and notes match the actual final state of the implementation.
  5. Confirm each success criterion has evidence - for every success criterion defined in the plan, record concrete evidence (command output, exit code, screenshot reference, or file path).

If checks fail

  • Fixable failures: fix the issue, re-run the failing check, and update the report with the corrected output.
  • Non-trivial failures: document the failure, the attempted fix, and the blocker in the report under "Failed checks and follow-ups". Escalate to the user before closing out.
  • Lint/format auto-fixes: if the tool supports auto-fix (e.g., ruff --fix, eslint --fix), apply it, then re-run to confirm clean output.

Validation report

Write to context/plans/{plan_name}.md including:

  • Commands run
  • Exit codes and key outputs
  • Failed checks and follow-ups
  • Success-criteria verification summary
  • Residual risks, if any

Example report entry

## Validation Report

### Commands run
- `npm test` -> exit 0 (42 tests passed, 0 failed)
- `eslint src/` -> exit 0 (no warnings)
- Removed: `src/debug_patch.js` (temporary scaffolding)

### Success-criteria verification
- [x] All API endpoints return 200 for valid input -> confirmed via test output line 34
- [x] Error responses include structured JSON -> confirmed via `test_error_format.js`

### Residual risks
- None identified.

Trustgrade A

  • passBody integrity

    Whether the stored document is plausibly the kind of file the artifact declares, rather than something fetched by mistake.

  • passType matchnot applicable to this artifact type

    Whether the artifact is really the kind of thing its metadata claims it is.

  • passFreshness

    How long since the source repository was last pushed to.

  • passPrompt injection

    Scans the artifact's own text for instructions aimed at your agent rather than at you.

  • passLicense

    Whether the source repository declares an SPDX license permissive enough to redistribute.

How the grade is calculated

Each check contributes 0 points when it passes, 1 when it warns, and 2 when it fails. The total maps to a letter:

  • Aevery check passed
  • Bone warning
  • Ctwo warnings
  • Dprompt injection or body integrity failed, or three warnings
  • Fone of those failed, and something else is wrong

These are automated hygiene checks, not a security audit, and not a dependency or vulnerability scan. A grade of A means nothing was flagged — not that the artifact is safe.

Versions

  • git-5b647df3fa6d2026-07-31