
Add Checkpoints
- 45 installs
- 2 repo stars
- Updated July 13, 2026
- netresearch/automated-assessment-skill
Helps with ai & agent building tasks.
About
add-checkpoints is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted coding.
- add-checkpoints
- AI & Agent Building
- AI-coding skill
Add Checkpoints by the numbers
- 45 all-time installs (skills.sh)
- Ranked #7,680 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/netresearch/automated-assessment-skill --skill add-checkpointsAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 45 |
|---|---|
| repo stars | ★ 2 |
| Last updated | July 13, 2026 |
| Repository | netresearch/automated-assessment-skill ↗ |
What it does
Helps with ai & agent building tasks.
Files
Add Checkpoints to a Skill
Analyze a skill and generate appropriate checkpoints.yaml for the automated-assessment framework.
Command
/add-checkpoints # Analyze current skill directory
/add-checkpoints typo3-docs # Analyze a specific installed skill
/add-checkpoints --dry-run # Show what would be generated, don't writeWorkflow
1. Locate the skill — find SKILL.md, references/, scripts/, assets/ 2. Analyze suitability — determine if checkpoints make sense (see criteria below) 3. Extract requirements — parse SKILL.md for verifiable rules and patterns 4. Generate checkpoints — create checkpoints.yaml with mechanical checks and LLM reviews 5. Add preconditions — determine which project types this skill applies to 6. Validate — run scripts/run-checkpoints.sh against a sample project to verify 7. Report — explain what was generated and why, or why checkpoints don't fit
Suitability Criteria
A skill is suitable for checkpoints if it defines:
- File structure requirements (directories, config files, manifests)
- Content patterns (must contain X, must not contain Y)
- Naming conventions (prefixes, suffixes, case rules)
- Tool configurations (PHPStan level, linter rules, CI steps)
- Metadata standards (license, author, version format)
A skill is NOT suitable if it only provides:
- Conceptual guidance without verifiable outputs
- Interactive workflows with no persistent artifacts
- Runtime behavior patterns (performance, caching strategies)
Report suitability with reasoning so the user can decide.
Checkpoint Generation Rules
Mechanical Checks
Extract from SKILL.md patterns like:
- "must exist" / "required" →
file_exists - "must not" / "never" / "avoid" →
file_not_existsornot_contains - "must contain" / "should have" →
containsorregex - Version/format constraints →
json_pathorcommand
Preconditions
Derive from the skill's scope:
- TYPO3 extensions →
file_exists: ext_emconf.php - Docker projects →
file_exists: Dockerfile - Go projects →
file_exists: go.mod - Skill repos →
file_exists: .claude-plugin/plugin.json - Universal (any project) → no preconditions
ID Convention
Use the skill's established prefix from references/migration-guide.md, or derive a 2-letter prefix from the skill name.
Severity Assignment
error: "must", "required", "never" → blocks releasewarning: "should", "recommended" → suggestioninfo: "consider", "nice to have" → optional
Calibration Anchor
Each checkpoint records its predicted defect class and retirement condition as YAML comments. Caps at info if missing. See automated-assessment/references/calibration.md.
LLM Reviews
For subjective requirements that can't be mechanically verified:
- Code quality judgments →
domain: code-quality - Documentation completeness →
domain: documentation - Architecture decisions →
domain: architecture
Group by domain, provide clear rubric prompts.
Output
Generates checkpoints.yaml in the skill's directory following the schema at references/checkpoints-schema.md. Also creates a copy in the automated-assessment assets directory.
References
- Schema:
references/checkpoints-schema.md - Migration guide:
references/migration-guide.md - Existing checkpoints:
assets/*-checkpoints.yaml(as examples)
{
"skill_name": "add-checkpoints",
"evals": [
{
"id": 1,
"eval_name": "add-checkpoints-to-skill",
"prompt": "Add checkpoints to the go-development skill. Analyze its SKILL.md and generate appropriate checkpoint YAML.",
"expected_output": "Analyzes the skill's SKILL.md, extracts verifiable requirements, generates checkpoints.yaml with mechanical checks and LLM reviews.",
"files": [],
"assertions": [
"Reads the target skill's SKILL.md to extract requirements",
"Generates a checkpoints.yaml file following the schema",
"Includes mechanical checks (file_exists, contains, regex) for verifiable rules",
"Includes LLM review checkpoints for subjective requirements",
"Adds appropriate preconditions (e.g., file_exists: go.mod for Go skills)",
"Assigns severity levels based on keyword strength (must/should/consider)"
]
},
{
"id": 2,
"eval_name": "evaluate-checkpoint-suitability",
"prompt": "Evaluate if this skill is suitable for checkpoints. It provides conceptual guidance about agile retrospectives with no file outputs.",
"expected_output": "Reports that the skill is NOT suitable for checkpoints because it lacks verifiable file outputs or structural requirements.",
"files": [],
"assertions": [
"Evaluates against suitability criteria from the skill",
"Identifies lack of file structure requirements",
"Identifies lack of verifiable content patterns",
"Reports NOT suitable with clear reasoning",
"Does not generate checkpoints for unsuitable skills"
]
}
]
}