| name | ssot-enforcement |
| description | Zero-tolerance SSoT enforcement across all repositories. Use when implementing ANY new code pattern, UI component, function, constant, or logic block. Triggers on all implementation work to enforce the mandatory pre-implementation grep check. Also use when reviewing code for duplication, discussing SSoT compliance, or when you notice yourself about to copy-paste code from one location to another. |
| user-invocable | false |
SSoT Enforcement — Zero Tolerance SOP
Core Rule
No copies. Ever. Not even on the 2nd occurrence.
The industry "Rule of Three" (copy once, abstract on third) is REJECTED. Every pattern, component, constant, or logic block must be a single source from the FIRST reuse.
If you are about to write something that already exists elsewhere — STOP. Extract it into a shared location FIRST, then use the SSoT version in both places.
Mandatory Pre-Implementation Check (Poka-Yoke)
Before writing ANY new UI component, function, constant, or pattern:
- GREP the codebase for similar patterns
- UI: search for class names, element structures, icon+text combinations
- Logic: search for function signatures, algorithm patterns
- Data: search for constant values, enum definitions, config shapes
- If a similar pattern exists ANYWHERE (even once):
- Extract it into a shared SSoT component/function FIRST
- Retrofit the existing location to use the SSoT version
- Then use it in the new location
- If no similar pattern exists: proceed normally — but design it as reusable from day one (accept props/params, don't hardcode)
What This Covers
| Category | Examples | SSoT Location |
|---|
| UI components | Loading spinners, empty states, error blocks, section headers, hint bars, badges | src/components/ (shared) |
| UI patterns | Collapsible sections, approval actions, card layouts | Extracted components with props |
| Data/config | Constants, enums, platform lists, feature flags | shared/constants.ts or similar |
| Logic | Validation, formatting, API patterns, hooks | src/hooks/, src/lib/, shared/ |
| Knowledge | Procedures, SOPs, documentation | Skills, not copy-pasted text |
Anti-Patterns (NEVER DO)
| Anti-Pattern | Correct Approach |
|---|
| Copy a component and tweak it | Extract shared component with props |
| Inline the same pattern twice | Extract to shared component on 2nd use |
Create ComponentV2 alongside Component | Extend Component with new props/options |
| Copy a constant to another file | Import from single source |
| "It's just 3 lines, not worth extracting" | Extract. Always. 3 lines x 10 files = 30 lines of debt |
| "I'll clean it up later" | Clean it up NOW. Deferred cleanup never happens. |
Recovery: When Duplication Is Found
When you discover existing duplication during implementation:
- STOP the current implementation
- Extract the duplicated pattern into SSoT first
- Retrofit all existing locations to use the SSoT version
- Then continue with the original implementation using the SSoT version
- Include the cleanup in the same commit/PR — don't defer it
Poka-Yoke: Current and Future
Current enforcement (context engineering):
- This skill's description triggers on all implementation work
- Claude's pre-implementation grep check catches duplicates before they're created
Future poka-yoke opportunities (not yet implemented):
- Pre-commit hook running
jscpd (copy-paste detector) — blocks commits with >N% duplication
- CI check flagging new files with high similarity to existing files
- RepoCoordinator periodic audit scanning repos for code clones