skill-maintenance
Guidelines for when and how to update Claude Code skills after codebase changes. Use after completing significant features, architectural changes, or discovering new patterns/anti-patterns. NOT for every commit - only meaningful changes that affect how agents should work.
$ インストール
git clone https://github.com/chaingraphlabs/chaingraph /tmp/chaingraph && cp -r /tmp/chaingraph/.claude/skills/skill-maintenance ~/.claude/skills/chaingraph// tip: Run this command in your terminal to install the skill
name: skill-maintenance description: Guidelines for when and how to update Claude Code skills after codebase changes. Use after completing significant features, architectural changes, or discovering new patterns/anti-patterns. NOT for every commit - only meaningful changes that affect how agents should work.
Skill Maintenance Guide
This skill helps development agents know when and how to update the ChainGraph skill tree after making codebase changes.
Core Principle: Balanced Updates
Skills should stay current but not churn constantly. Update skills for meaningful changes that affect how future agents should work.
┌─────────────────────────────────────┐
│ SKILL UPDATE DECISION │
└─────────────────────────────────────┘
│
┌────────────────┴────────────────┐
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ UPDATE │ │ DON'T UPDATE │
└──────────────┘ └──────────────┘
• New architecture • Bug fixes
• New patterns • Small features
• New anti-patterns • Refactoring
• API changes • Test changes
• Critical constraints • Documentation
When to UPDATE Skills
Architectural Changes
- New store domain added
- New component pattern established
- New file organization structure
- New package added to monorepo
Pattern Discovery
- Found a better way to do something common
- Discovered a pattern that should be standard
- Created a reusable hook/utility worth documenting
Anti-Pattern Discovery
- Found code that causes bugs/issues
- Discovered performance problems from certain patterns
- Identified security concerns
API/Interface Changes
- tRPC procedure signature changed
- Store API changed (new events, effects)
- Decorator API changed
- DBOS workflow patterns changed
Critical Constraints
- New rule that MUST be followed
- Breaking change that affects existing code
- Deprecation of old patterns
When NOT to Update Skills
Routine Development
- Bug fixes (unless revealing anti-pattern)
- Small feature additions
- Refactoring that doesn't change patterns
- Test additions/modifications
Documentation Changes
- README updates
- Code comments
- JSDoc additions
Cosmetic Changes
- Renaming (unless widespread)
- Code formatting
- Import reorganization
Work in Progress
- Experimental features
- Incomplete implementations
- Features behind feature flags
How to Update Skills
Step 1: Identify Affected Skills
Ask: "Which skills would an agent need to know about this change?"
| Change Type | Likely Affected Skills |
|---|---|
| New Effector pattern | effector-patterns |
| Frontend architecture | frontend-architecture |
| New port type | port-system, types-architecture |
| DBOS workflow change | dbos-patterns, executor-architecture |
| Subscription change | subscription-sync |
| New node pattern | node-creation, types-architecture |
Step 2: Determine Update Type
Add Pattern: New recommended way to do something
## Patterns
### New: Using usePortValue hook
Prefer `usePortValue(portKey)` over direct store subscription...
Add Anti-Pattern: New thing to avoid
## Anti-Patterns
### Avoid: Direct $portValues subscription in components
❌ Bad: `useUnit($portValues)` - causes re-render on ANY port change
✅ Good: `usePortValue(portKey)` - subscribes to single port
Update Example: Code example is outdated
// Updated: Now uses ports-v2 API
const value = usePortValue(portKey)
Update File Reference: File moved or renamed
| `src/store/ports-v2/stores.ts` | Port value stores (was ports/stores.ts) |
Deprecate Pattern: Old way is no longer recommended
### Deprecated: Legacy port stores
The `ports/` store is deprecated. Use `ports-v2/` instead.
Migration guide: [link to migration docs]
Step 3: Make Minimal Changes
- Add new information, don't rewrite everything
- Keep existing structure
- Add date/context in comments if helpful:
### Using CommandController (added after dd543528)
Step 4: Verify Consistency
- Does this change conflict with other skills?
- Should other skills reference this new pattern?
- Is the skill still under 500 lines?
Skill Update Checklist
After significant development work, ask:
- Did I introduce a new pattern that should be documented?
- Did I discover an anti-pattern that others should avoid?
- Did I change architecture that affects how agents work?
- Did I add new files/folders that should be in Key Files?
- Did I create new constraints that MUST be followed?
- Did I deprecate something that skills still recommend?
If any are YES, update the relevant skill(s).
Update Frequency Guidelines
| Skill Type | Update Frequency |
|---|---|
Foundation (chaingraph-concepts) | Rarely - core concepts stable |
Package (*-architecture) | Monthly - as architecture evolves |
Technology (*-patterns) | When patterns discovered/deprecated |
Feature (port-system, etc.) | When feature area changes significantly |
Meta (skill-*) | When skill conventions change |
Example: When to Update
Scenario: Added new echo detection mechanism
Changes made:
- Added
echo-detection.tsinports-v2/ - New 3-step detection: mutation match → staleness → duplicate
- Added
$pendingPortMutationsstore
Skills to update:
-
optimistic-updates(Primary)- Add section on 3-step echo detection
- Document
$pendingPortMutationsstore - Add anti-pattern: forgetting to track mutations
-
frontend-architecture(Reference)- Add
echo-detection.tsto Key Files - Mention echo detection in ports-v2 section
- Add
-
effector-patterns(Optional)- If the pattern is reusable beyond ports
Scenario: Fixed a bug in array port rendering
Changes made:
- Fixed race condition in
ArrayPort.tsx - Added null check
Skills to update: NONE
- This is a bug fix, not a pattern change
- Unless: the bug revealed an anti-pattern worth documenting
Scenario: Refactored store structure
Changes made:
- Renamed
ports/→ports-v2/ - Migration mode: disabled → dual-write → read-only → full
- All new code should use ports-v2
Skills to update:
-
frontend-architecture- Update folder structure
- Document migration modes
- Add deprecation notice for old
ports/
-
effector-patterns- Document migration pattern if reusable
-
port-system- Update all references to use ports-v2
- Add migration guide section
Commit Message Convention
When updating skills, use clear commit messages:
docs(skills): update effector-patterns with new sample() usage
- Added pattern for combining multiple sources
- Documented anti-pattern for nested samples
- Updated Key Files with new store locations
Skill Health Metrics
Periodically review skills for staleness:
| Metric | Healthy | Needs Review |
|---|---|---|
| Last updated | < 3 months | > 6 months |
| Key Files exist | All exist | Files missing |
| Patterns work | Code compiles | Outdated syntax |
| Anti-patterns relevant | Still problematic | Fixed in codebase |
Related Skills
skill-authoring- For creating new skills- See package-specific skills for what to update in each area
Repository
