Update practices
Configuration governance for Claude Code. Bootstrap, audit, sync, and evolve .claude/ across projects.
npx -y skills add luiseiman/dotforge --skill update-practicesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Process the practices inbox, evaluate, incorporate into dotforge, and suggest propagation to projects.
SKILL.md
5.3 KB, as published. Nobody here has run it
Update Practices
3-phase pipeline to keep dotforge up to date with discovered practices.
Practice sources:
- Post-session hook (
detect-claude-changes.sh) → automatic - Manual capture (
/forge capture) → user - For manual web search: research and then use
/forge capturewith the findings
Phase 1: EVALUATE — Process inbox
Read all files in $DOTFORGE_DIR/practices/inbox/.
For each practice:
Acceptance criteria
- Is it actionable? — Can be translated into a concrete change in dotforge
- Is it new? — Does not duplicate something already in
practices/active/ - Is it generalizable? — Applies to >1 project (not project-specific)
- Does it prevent a specific error? — If yes, annotate
error_typeand error description for tracking in metrics.yml
Classify
- Accept → move to
practices/evaluating/, note proposed concrete change - Reject → remove from inbox with a note explaining why
- Defer → leave in inbox with tag
needs-more-info
Priority
- Security (vulnerabilities, permissions)
- Breaking changes (APIs that changed)
- New features that simplify something existing
- Patterns validated in >1 project
- Minor optimizations
Show summary:
═══ INBOX EVALUATION ═══
{{N}} practices in inbox
✅ ACCEPT: {{title}} → {{proposed change}}
❌ REJECT: {{title}} → {{reason}}
⏸️ DEFER: {{title}} → {{what is missing}}
Proceed with accepted? (yes/no/select)
Phase 2: INCORPORATE — Apply changes to dotforge
For each accepted practice in evaluating/:
Determine impact
| Change type | Affected files | Version bump |
|---|---|---|
| New/modified rule | template/rules/, stacks/*/rules/ | minor |
| New/modified hook | template/hooks/, stacks/*/hooks/ | minor |
| Documentation | docs/*.md | patch |
| Modified template | template/*.tmpl | minor |
| Security fix | any | patch |
Apply
- Show proposed diff to the user and ask for confirmation
- Modify the corresponding dotforge files
- If the practice warrants a new rule: generate a
.mdfile intemplate/rules/orstacks/*/rules/with properglobs:(eager) orpaths:+alwaysApply: false(lazy) frontmatter. Only create a rule if the practice is a repeatable constraint (not a one-time fix). Use existing rules as format reference. - Move practice from
evaluating/toactive/withincorporated_in:updated - Set frontmatter fields:
effectiveness: monitoring(orinformationalif no error targeted — informational is excluded from the validation rate metric),error_typematching CLAUDE_ERRORS.md types - Register in
$DOTFORGE_DIR/practices/metrics.yml:error_targeted: description of the error this practice prevents (null if not error-targeted)error_type: syntax | logic | integration | config | security | nullactivated: today's datestatus: monitoring (or informational — for general-knowledge practices, never validated)recurrence_checks: 0recurrence_target: 5
- Update
docs/changelog.md - Bump
VERSIONaccording to type
Phase 3: PROPAGATE — Suggest project updates
- Read
$DOTFORGE_DIR/registry/projects.yml - For each project, show what changed since its last sync:
═══ SUGGESTED PROPAGATION ═══
project-a (last sync: {{date or "never"}})
→ {{N}} rules updated
project-b (last sync: {{date or "never"}})
→ {{N}} rules updated
To propagate: run /forge sync in each project.
DO NOT propagate automatically. Inform only.
Phase 4: VERIFY — Recurrence check for active practices
For each entry in $DOTFORGE_DIR/practices/metrics.yml where status: monitoring:
- Read
CLAUDE_ERRORS.mdfrom each project in registry where the practice is applied - Check if any error matching
error_type+error_targeteddescription was logged AFTER theactivateddate - Increment
recurrence_checksby 1, updatelast_checkedto today - If error recurred: set
recurred: true,status: failed - If
recurrence_checks >= recurrence_targetandrecurred: false: setstatus: validated - Update
effectivenessfield in the practice's frontmatter file to match
Report:
═══ EFFECTIVENESS CHECK ═══
{{practice title}} — {{status}} ({{recurrence_checks}}/{{recurrence_target}} checks)
{{if failed: "⚠ Error recurred — practice needs revision"}}
{{if validated: "✅ No recurrence after {{N}} checks"}}
{{if monitoring: "🔍 {{remaining}} checks remaining"}}
Skip practices with status: informational or status: validated. Informational practices are general-knowledge captures — they don't target an error, so recurrence is undefined and they never enter the validation rate.
Final report
═══ UPDATE REPORT ═══
Date: {{YYYY-MM-DD}}
Evaluated: {{N}} ({{accepted}} accepted, {{rejected}} rejected, {{deferred}} deferred)
Incorporated: {{N}} into dotforge
Propagation suggested: {{N}} projects
── EFFECTIVENESS ──
Monitoring: {{N}} practices
Validated: {{N}} (no recurrence after {{target}} checks)
Failed: {{N}} (need revision)
VERSION: {{old}} → {{new}}