check-cross-layer
Skill1 starsChanged 7 months agoMITView on GitHub
Post-implementation verification across multiple code dimensions: cross-layer data flow, code reuse analysis, import path validation, and same-layer consistency checks. Identifies missed update sites, type mismatches, and duplicated constants. Use when changes span 3+ architectural layers, after modifying shared constants or configs, after batch file modifications, or when creating new utility functions.
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/macs-protocol.mdcCursor rule
- before-devSkill
- brainstormSkill
- break-loopSkill
- checkSkill
- create-commandSkill
- finish-workSkill
- improve-utSkill
- integrate-skillSkill
- onboardSkill
- record-sessionSkill
- startSkill
- update-specSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Check if your changes considered all dimensions.
- Distinctive: line 157
Check results for each dimension
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Cross-Layer Check
Check if your changes considered all dimensions. Most bugs come from "didn't think of it", not lack of technical skill.
Note: This is a post-implementation safety net. Ideally, read the Pre-Implementation Checklist before writing code.
Related Documents
| Document | Purpose | Timing |
| Pre-Implementation Checklist | Questions before coding | Before writing code |
| Code Reuse Thinking Guide | Pattern recognition | During implementation |
$check-cross-layer (this skill) | Verification check | After implementation |
Execution Steps
1. Identify Change Scope
git status
git diff --name-only2. Select Applicable Check Dimensions
Based on your change type, execute relevant checks below:
Dimension A: Cross-Layer Data Flow (Required when 3+ layers)
Trigger: Changes involve 3 or more layers
| Layer | Common Locations |
| API/Routes | routes/, api/, handlers/, controllers/ |
| Service/Business Logic | services/, lib/, core/, domain/ |
| Database/Storage | db/, models/, repositories/, schema/ |
| UI/Presentation | components/, views/, templates/, pages/ |
| Utility | utils/, helpers/, common/ |
Checklist:
- Read flow: Database -> Service -> API -> UI
- Write flow: UI -> API -> Service -> Database
- Types/schemas correctly passed between layers?
- Errors properly propagated to caller?
- Loading/pending states handled at each layer?
Detailed Guide: .trellis/spec/guides/cross-layer-thinking-guide.md
Dimension B: Code Reuse (Required when modifying constants/config)
Trigger:
- Modifying UI constants (label, icon, color)
- Modifying any hardcoded value
- Seeing similar code in multiple places
- Creating a new utility/helper function
- Just finished batch modifications across files
Checklist:
- Search first: How many places define this value?
# Search in source files (adjust extensions for your project) grep -r "value-to-change" src/ - If 2+ places define same value -> Should extract to shared constant
- After modification, all usage sites updated?
- If creating utility: Does similar utility already exist?
Detailed Guide: .trellis/spec/guides/code-reuse-thinking-guide.md
Dimension B2: New Utility Functions
Trigger: About to create a new utility/helper function
Checklist:
- Search for existing similar utilities first
grep -r "functionNamePattern" src/ - If similar exists, can you extend it instead?
- If creating new, is it in the right location (shared vs domain-specific)?
Dimension B3: After Batch Modifications
Trigger: Just modified similar patterns in multiple files
Checklist:
- Did you check ALL files with similar patterns?
grep -r "patternYouChanged" src/ - Any files missed that should also be updated?
- Should this pattern be abstracted to prevent future duplication?
Dimension C: Import/Dependency Paths (Required when creating new files)
Trigger: Creating new source files
Checklist:
- Using correct import paths (relative vs absolute)?
- No circular dependencies?
- Consistent with project's module organization?
Dimension D: Same-Layer Consistency
Trigger:
- Modifying display logic or formatting
- Same domain concept used in multiple places
Checklist:
- Search for other places using same concept
grep -r "ConceptName" src/ - Are these usages consistent?
- Should they share configuration/constants?
Common Issues Quick Reference
| Issue | Root Cause | Prevention |
| Changed one place, missed others | Didn't search impact scope | grep before changing |
| Data lost at some layer | Didn't check data flow | Trace data source to destination |
| Type/schema mismatch | Cross-layer types inconsistent | Use shared type definitions |
| UI/output inconsistent | Same concept in multiple places | Extract shared constants |
| Similar utility exists | Didn't search first | Search before creating |
| Batch fix incomplete | Didn't verify all occurrences | grep after fixing |
Output
Report:
- Which dimensions your changes involve
- Check results for each dimension
- Issues found and fix suggestions
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.