Agent skill
clayers-review-artifacts
Review and improve artifact mappings for end-to-end coverage between specification and code. Analyzes both directions (spec-to-code and code-to-spec), identifies gaps, improves mapping granularity, resolves drift with root-cause analysis, and validates exemptions. Use when: "review artifacts", "check coverage", "fix drift", "clayers-review-artifacts", "improve mapping quality", "drive coverage to 100%".
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/other/clayers-review-artifacts
SKILL.md
Clayers Review Artifacts
Review and improve artifact mappings for main to achieve end-to-end traceability between specification and code.
Goal: Every spec node maps to code. Every code region maps to a spec node. Coverage is precise (small ranges, focused nodes). Drift is zero. Exemptions are justified.
Before You Start
Run all quality checks to establish baseline:
clayers artifact --coverage clayers/main/
clayers artifact --drift clayers/main/
clayers connectivity clayers/main/
clayers validate clayers/main/
Record the numbers: total nodes, mapped, exempt, unmapped, drifted. These are your starting point.
If --rev argument was provided, also check out the previous revision
and run coverage there for comparison (see Phase 7).
Phase 1: Spec-to-Code Coverage (Unmapped Nodes)
Question: Which spec nodes have no artifact mapping?
clayers artifact --coverage clayers/main/
Look at the "unmapped nodes" section. For EACH unmapped node:
1.1 Determine if the node describes code
Read the node content:
clayers query clayers/main/ '//*[@id="NODE_ID"]' --text
Ask: Does this node describe something implemented in code?
| Node type | Likely maps to code? | Example |
|---|---|---|
| Algorithm, data structure, function | Yes | "Binary search implementation" |
| API endpoint, CLI command | Yes | "The validate command" |
| Data type, struct, enum | Yes | "ArtifactMapping struct" |
| Configuration, schema definition | Yes | "XSD schema for prose layer" |
| Design rationale, motivation | No | "Why we chose SHA-256" |
| Process description, workflow | Maybe | Depends if code implements it |
| Abstract concept, philosophy | No | "Spec-first methodology" |
| Future work, roadmap item | No | "Planned: git integration" |
1.2 If YES: Create an artifact mapping
Find the implementing code. Search by:
- Function/type names mentioned in the spec prose
- File paths mentioned in related mappings
- Module structure matching the concept
Create a precise mapping. Prefer:
| Approach | Coverage strength | Prefer? |
|---|---|---|
| Specific function (20 lines) | Precise | Yes |
| Module section (80 lines) | Moderate | OK |
| Entire file (500 lines) | Broad | Avoid |
<art:mapping id="map-{descriptive-name}">
<art:spec-ref node="{NODE_ID}"
revision="draft-1"
node-hash="sha256:placeholder"/>
<art:artifact repo="main"
repo-revision="HEAD"
path="{path/to/file}">
<art:range hash="sha256:placeholder"
start-line="{start}" end-line="{end}"/>
</art:artifact>
<art:coverage>full</art:coverage>
<art:note>{What this code implements from the spec node.}</art:note>
</art:mapping>
If the implementation spans multiple non-contiguous ranges, use
multiple <art:range> elements in a single mapping.
After adding mappings:
clayers artifact --fix-node-hash clayers/main/
clayers artifact --fix-artifact-hash clayers/main/
1.3 If NO: Exempt with justification
Think carefully before exempting. Ask yourself:
- Is this truly abstract? Or is there code that realizes this concept?
- Could the concept be decomposed? Maybe the abstract part is exempt but a concrete sub-aspect maps to code.
- Am I being lazy? If the code is hard to find, that's not a reason to exempt.
If unsure, ask the user. Present the node content and your reasoning.
To exempt:
<art:exempt node="{NODE_ID}"/>
Always add a comment explaining WHY:
<!-- Exempt: design rationale with no implementing code -->
<art:exempt node="dec-why-sha256"/>
1.4 Validate after each batch
clayers validate clayers/main/
clayers artifact --coverage clayers/main/
Success criteria: Zero unmapped nodes (all mapped or explicitly exempted).
Phase 2: Code-to-Spec Coverage (Uncovered Code)
Question: Which code regions have no spec node describing them?
clayers artifact --coverage clayers/main/ --code-path src/
Look at the "code coverage" section. For EACH file with uncovered ranges:
2.1 Analyze uncovered ranges
For each NOT COVERED range, read the code:
- What does this code do?
- Is it a distinct concept, or part of an already-mapped concept?
- Is it boilerplate/generated code that doesn't need spec coverage?
2.2 Extend existing mapping or create new spec node
Option A: The code implements an already-described concept.
Extend the existing mapping by adding another <art:range>:
<!-- Add a range to an existing mapping -->
<art:mapping id="map-existing">
<art:spec-ref node="existing-concept" .../>
<art:artifact ...>
<art:range ... start-line="10" end-line="50"/>
<!-- NEW: additional range for uncovered code -->
<art:range hash="sha256:placeholder"
start-line="80" end-line="95"/>
</art:artifact>
</art:mapping>
Option B: The code implements a new concept not yet in the spec. Create the spec node first (spec-first!), then map it:
- Add
<pr:section>,<org:concept>,<rel:relation>,<llm:node> - Register in index.xml if new file
- Create
<art:mapping>with precise line ranges - Fix hashes
2.3 Decompose broad mappings
If a file shows 100% coverage but all from one broad mapping (e.g., whole-file with 500 lines), consider splitting:
- Identify distinct logical sections within the file
- Create separate spec nodes for each section
- Replace the single broad mapping with multiple precise mappings
- Each mapping covers 10-80 lines ideally
Coverage strength targets:
| Strength | Lines | Quality | Action |
|---|---|---|---|
| Precise | 1-30 | Excellent | Keep |
| Moderate | 31-100 | Good | Keep or split if >80 |
| Broad | 101+ | Poor | Always split |
Check current mapping strengths:
clayers artifact --coverage clayers/main/
The output shows strength per mapping (e.g., map-id: file.rs (150 lines, Broad)).
Success criteria: Maximize code line coverage. No Broad mappings
unless the code is genuinely monolithic.
Phase 3: Drift Resolution
Question: Are stored hashes consistent with current content?
clayers artifact --drift clayers/main/
For each drifted mapping, do NOT blindly fix. Analyze first.
3.1 ARTIFACT DRIFTED (code changed)
The code at the mapped lines changed. Investigate:
# What changed in this file?
git log --oneline -10 -- {file_path}
git diff HEAD~5 -- {file_path}
Determine the cause:
| Cause | Action |
|---|---|
| Lines shifted (refactor, added code above) | Update start-line/end-line, then --fix-artifact-hash |
| Function renamed/moved | Find new location, update path and/or line ranges |
| Semantic change (logic rewritten) | Review spec prose, update if needed, then fix hashes |
| Function deleted | Remove mapping, possibly remove/update spec node |
| File renamed/moved | Update path attribute |
To update line ranges after a shift:
- Find where the function actually is now:
bash
grep -n 'fn function_name' {file_path} - Update
start-lineandend-linein the mapping - Run
clayers artifact --fix-artifact-hash clayers/main/ - Verify:
clayers artifact --drift clayers/main/
Pattern matching for line shifts: If many mappings in the same file drifted, it's likely a line shift. Calculate the offset (new_line - old_line) and apply uniformly.
3.2 SPEC DRIFTED (spec node changed)
The spec prose for a mapped node changed. This means the description evolved but the mapping hash is stale.
clayers artifact --fix-node-hash clayers/main/
Then verify the mapping still makes sense: does the code still implement what the spec now describes? If the spec changed significantly, the code mapping may need updating too.
3.3 UNAVAILABLE (file or node missing)
The mapped artifact can't be found. Possible causes:
- File was deleted or renamed
- Path is wrong (typo, different repo layout)
- Node ID was changed
Fix: Find the correct path/ID or remove the mapping.
3.4 Post-drift validation
After fixing all drift:
clayers artifact --drift clayers/main/
clayers artifact --coverage clayers/main/
clayers validate clayers/main/
Coverage may have changed after drift fixes (line ranges moved, files renamed). Re-run coverage and fix any new gaps.
Success criteria: Zero drifted mappings.
Phase 4: Exemption Audit
Question: Are all exemptions justified?
List current exemptions:
clayers query clayers/main/ '//art:exempt/@node' --text
For EACH exempted node:
-
Read the node:
bashclayers query clayers/main/ '//*[@id="NODE_ID"]' --text -
Ask: Is this STILL exempt-worthy?
- Did someone add implementing code since the exemption?
- Was the node refined to be more concrete?
- Could part of it now be mapped even if the whole can't?
-
If the exemption is no longer valid: Remove
<art:exempt>and create an artifact mapping instead. -
If unsure: Ask the user. Present the node content and explain your reasoning for keeping or removing the exemption.
Success criteria: Every exemption has a clear justification. No node is exempted just because finding its code is difficult.
Phase 5: Mapping Quality Review
Question: Are mappings precise and well-described?
5.1 Check mapping strengths
clayers artifact --coverage clayers/main/
For each mapping, the output shows line count and strength classification. Target: majority of mappings should be Precise (1-30 lines) or Moderate (31-100 lines).
5.2 Split broad mappings
For any mapping classified as Broad (101+ lines):
- Read the mapped code range
- Identify logical sub-sections (functions, blocks, types)
- Create separate spec sub-sections for each
- Split the single mapping into multiple precise mappings
- Each sub-mapping gets its own
<art:note>explaining what it covers
5.3 Check mapping notes
Every mapping should have a descriptive <art:note>. Review:
- Does the note explain WHAT the code implements?
- Would someone reading only the note understand the mapping?
- Is the note current (matches what the code actually does)?
5.4 Check coverage values
Each mapping has <art:coverage>full</art:coverage> or partial.
Verify:
full: the mapped range completely implements the spec nodepartial: the mapped range only partially implements it- Are there other ranges that complete the implementation?
- Should additional ranges be added?
5.5 Spec node granularity
If a single spec node has many mappings pointing to it, the node may be too broad. Consider decomposing:
# How many mappings per node?
clayers query clayers/main/ '//art:mapping/art:spec-ref/@node' --text
Count occurrences. If one node has 10+ mappings, it probably needs to be split into sub-sections, each with their own mappings.
Success criteria: No Broad mappings. Every mapping has a descriptive note. Coverage values are accurate.
Phase 6: Connectivity Cross-Check
Question: Are mapped nodes well-connected in the spec graph?
clayers connectivity clayers/main/
Newly mapped nodes sometimes lack relations. For each node you mapped or modified:
- Does it have at least one
<rel:relation>? - Is it connected to the main component (not isolated)?
- Are
depends-on/refines/referencesrelations accurate?
Fix isolated nodes by adding relations.
Success criteria: Zero isolated nodes.
Phase 7: Revision Comparison (Optional)
Use when --rev argument is provided, or when you need to understand
how coverage changed between revisions.
7.1 Compare coverage across revisions
# Current coverage
clayers artifact --coverage clayers/main/
# Compare with a specific revision
git stash # Save current work
git checkout {REV}
clayers artifact --coverage clayers/main/
git checkout - # Return
git stash pop # Restore work
7.2 Analyze changes
Compare the two reports:
- New unmapped nodes: Spec grew but mappings didn't keep up
- New uncovered code: Code grew but spec didn't keep up
- Changed coverage %: Lines shifted, mappings drifted
- New/removed exemptions: Review justifications
7.3 Trace specific drift
For mappings that drifted between revisions:
git diff {OLD_REV}..HEAD -- {artifact_path}
This shows exactly what changed in the code, helping you decide whether to update line ranges or update the spec.
Phase 8: Final Verification
Run the full check suite:
# 1. Structural validation
clayers validate clayers/main/
# 2. Drift detection (exit code 0 = clean)
clayers artifact --drift clayers/main/
# 3. Coverage analysis
clayers artifact --coverage clayers/main/
# 4. Connectivity
clayers connectivity clayers/main/
All must be clean:
- Validation: OK
- Drift: 0 drifted
- Coverage: 0 unmapped nodes, no Broad mappings
- Connectivity: 0 isolated nodes
Report to the user:
- Starting state (from "Before You Start")
- Ending state (current numbers)
- What was added/changed/exempted
- Any decisions that need user input
Decision Framework: Map vs. Exempt
When you're unsure whether a node should be mapped or exempted, use this framework:
Always map (never exempt)
- Functions, methods, implementations
- Data types (structs, enums, classes)
- CLI commands and handlers
- API endpoints
- Configuration schemas
- Test suites (map to the code they test)
- Constants and type definitions
Usually exempt (but consider carefully)
- Design decisions (
dec:decisionelements) that explain WHY - Historical context that doesn't correspond to current code
- Methodology descriptions (how to use clayers, not clayers itself)
- Future work items not yet implemented
- Cross-cutting concerns described once but implemented everywhere
Ask the user when
- A concept is partially implemented (map the partial part?)
- The implementing code is in a different repository
- The node describes emergent behavior (no single code location)
- You found code that seems related but aren't sure
- The boundary between abstract and concrete is unclear
Default: Map. Only exempt when you're confident there is truly no implementing code. When in doubt, ask.
Anti-Patterns to Avoid
| Anti-pattern | Problem | Better approach |
|---|---|---|
| Whole-file mapping | Broad, imprecise | Split into function-level ranges |
| Copy-paste line numbers without reading | Ranges may be wrong | Always read the code at those lines |
| Exempting because code is hard to find | Hides gaps | Search harder, ask user |
| Fixing hashes without analyzing drift | Masks real changes | Understand what changed first |
| One spec node with 10 mappings | Node too broad | Decompose into sub-sections |
| Mapping to comments or blank lines | Inflates coverage | Map to actual logic |
| Skipping connectivity after changes | Isolated nodes | Always check connectivity |
| Trusting old line ranges | Code shifts happen | Verify current positions |
| Self-referential mapping (spec file maps to itself) | Spec files are both spec and artifact; editing the spec changes the artifact hash, creating infinite drift loops | Exempt the node or map to non-spec code only. Never map a spec XML file to itself as an artifact |
Quick Reference: Commands
# Coverage (both directions)
clayers artifact --coverage clayers/main/
clayers artifact --coverage clayers/main/ --code-path src/
# Drift
clayers artifact --drift clayers/main/
# Fix hashes
clayers artifact --fix-node-hash clayers/main/
clayers artifact --fix-artifact-hash clayers/main/
# Query spec
clayers query clayers/main/ '//art:exempt/@node' --text
clayers query clayers/main/ '//art:mapping/art:spec-ref/@node' --text
clayers query clayers/main/ '//*[@id="NODE_ID"]' --text
clayers query clayers/main/ '//art:mapping' --count
# Connectivity
clayers connectivity clayers/main/
# Validate
clayers validate clayers/main/
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?