update-practices
Skill8 starsChanged 7 months agoMITView on GitHub
Process the practices inbox, evaluate, incorporate into dotforge, and suggest propagation to projects.
In this repository20 other files it gives its agents.
- .claude/rules/agents.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- audit-projectSkill
- bootstrap-projectSkill
- capture-practiceSkill
- diff-projectSkill
- domain-extractSkill
- export-configSkill
- forge-behaviorSkill
- init-projectSkill
- learn-projectSkill
- mcp-addSkill
- plugin-generatorSkill
- reset-projectSkill
- rule-effectivenessSkill
- scout-reposSkill
- session-insightsSkill
- sync-all-reposSkill
- sync-templateSkill
- watch-upstreamSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 1 is distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 19
Read all files in $DOTFORGE_DIR/practices/inbox/.
- Distinctive: line 103
DO NOT propagate automatically.
- Very specific: line 111
Read CLAUDE_ERRORS.md from each project in registry where the practice is applied
- Very specific: line 112
Check if any error matching error_type + error_targeted description was logged AFTER the activated date
- Very specific: line 114
If error recurred: set recurred: true, status: failed
- Very specific: line 115
If recurrence_checks >= recurrence_target and recurred: false: set status: validated
- Very specific: line 116
Update effectiveness field in the practice's frontmatter file to match
≈ “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
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.local.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}}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.

