Automated Assessment

Automated Assessment Skill

Systematic compliance assessment against checkpoint-enabled skills.

Usage

/assess                              # All matching skills
/assess skill-repo typo3-testing     # Specific skills only
/assess --force                      # Ignore preconditions
/assess --mechanical-only            # Scripted checks only
/assess --autofix                    # Fix issues automatically
/assess --review                     # Categorize failures
/assess --autoimprove                # Fix + propose improvements
/assess dependency-compatibility     # Dependency compat checks
/assess --pre-push                   # Pre-push validation gate
/assess --check-coverage             # Verify checkpoint coverage

Options

Steps

1. Discover skills, evaluate preconditions
2. Run mechanical checkpoints
3. Group LLM checkpoints by domain, spawn parallel agents
4. Collect results, generate report

Assessment-First Rule

CRITICAL: Run /assess BEFORE manual quality work (enhance tests, improve coverage, strengthen suite, upgrade PHPStan, etc.). Assessment generates a structured gap analysis, preventing wasted iterative discovery.

Workflow

1. /assess with relevant skills
2. Review gap report — this becomes the task list
3. Fix in priority order (errors before warnings; use --autofix for automated resolution)
4. Re-run /assess to verify

Checkpoint Types

Mechanical: file_exists, file_not_exists, contains, not_contains, regex, json_path, gh_api, command. LLM: llm_review (grouped by domain). See references/checkpoints-schema.md.

Domains

repo-health security code-quality documentation git-workflow docker ddev upgrade dependency-compatibility pre-push

Autofix & Review

--autofix invokes responsible skill for failures, re-verifies. Statuses: auto-fixed, needs-review, unfixable. --review/--autoimprove create feedback loops.

Pre-Push Gate

Only installed tools (vendor/bin/*) are checked. Missing tools pass. IDs: PP-01 (PHPStan), PP-02 (PHPUnit), PP-03 (PHP-CS-Fixer), PP-04 (Rector).

Severity

error = blocks release, warning = recommendation, info = optional.

Outcomes

pass fail skip blocked — counted separately (total == pass + fail + skip + blocked).

Never report a blocked checkpoint as a finding. It means the runner refused the command through its allowlist, so nothing was measured: the defect is in the checkpoint file, not in the assessed project. Report blocked checkpoints as broken checks, run scripts/validate-checkpoints.sh <file> against the owning skill, and file them there. A refused precondition is the same thing one level up — the JSON reason says REFUSED by the runner allowlist, which is not the same as "this skill does not apply". See references/checkpoints-schema.md → "Outcomes".

References

• references/checkpoints-schema.md -- Checkpoint YAML schema and types
• references/learning-derived-checkpoints.md -- Retro-to-checkpoint routing contract
• references/checkpoint-coverage-requirements.md -- Required coverage categories per skill
• references/checkpoint-workflow.md -- Full assessment workflow with autofix loop
• references/calibration.md -- Calibration debt, audit cadence, anchor at generation time, ratchet anti-pattern
• references/dependency-compatibility.md -- Multi-major-version assessment trigger
• references/migration-guide.md -- Adding checkpoints to existing skills
• references/verification-patterns.md -- Verification patterns and result schemas