agentleFS
luiseimanluiseiman/dotforge/skills/update-practices/SKILL.md

update-practices

Skill8 starsChanged 7 months agoMITView on GitHub

Process the practices inbox, evaluate, incorporate into dotforge, and suggest propagation to projects.

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
  1. Very specific:

    Read all files in $DOTFORGE_DIR/practices/inbox/.

    line 19
  2. Distinctive:

    DO NOT propagate automatically.

    line 103
  3. Very specific:

    Read CLAUDE_ERRORS.md from each project in registry where the practice is applied

    line 111
  4. Very specific:

    Check if any error matching error_type + error_targeted description was logged AFTER the activated date

    line 112
  5. Very specific:

    If error recurred: set recurred: true, status: failed

    line 114
  6. Very specific:

    If recurrence_checks >= recurrence_target and recurred: false: set status: validated

    line 115
  7. Very specific:

    Update effectiveness field in the practice's frontmatter file to match

    line 116

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 capture with the findings

Phase 1: EVALUATE — Process inbox

Read all files in $DOTFORGE_DIR/practices/inbox/.

For each practice:

Acceptance criteria

  1. Is it actionable? — Can be translated into a concrete change in dotforge
  2. Is it new? — Does not duplicate something already in practices/active/
  3. Is it generalizable? — Applies to >1 project (not project-specific)
  4. Does it prevent a specific error? — If yes, annotate error_type and 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

  1. Security (vulnerabilities, permissions)
  2. Breaking changes (APIs that changed)
  3. New features that simplify something existing
  4. Patterns validated in >1 project
  5. 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 typeAffected filesVersion bump
New/modified ruletemplate/rules/, stacks/*/rules/minor
New/modified hooktemplate/hooks/, stacks/*/hooks/minor
Documentationdocs/*.mdpatch
Modified templatetemplate/*.tmplminor
Security fixanypatch

Apply

  1. Show proposed diff to the user and ask for confirmation
  2. Modify the corresponding dotforge files
  3. If the practice warrants a new rule: generate a .md file in template/rules/ or stacks/*/rules/ with proper globs: (eager) or paths: + 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.
  4. Move practice from evaluating/ to active/ with incorporated_in: updated
  5. Set frontmatter fields: effectiveness: monitoring (or informational if no error targeted — informational is excluded from the validation rate metric), error_type matching CLAUDE_ERRORS.md types
  6. 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 | null
    • activated: today's date
    • status: monitoring (or informational — for general-knowledge practices, never validated)
    • recurrence_checks: 0
    • recurrence_target: 5
  7. Update docs/changelog.md
  8. Bump VERSION according to type

Phase 3: PROPAGATE — Suggest project updates

  1. Read $DOTFORGE_DIR/registry/projects.local.yml
  2. 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:

  1. Read CLAUDE_ERRORS.md from each project in registry where the practice is applied
  2. Check if any error matching error_type + error_targeted description was logged AFTER the activated date
  3. Increment recurrence_checks by 1, update last_checked to today
  4. If error recurred: set recurred: true, status: failed
  5. If recurrence_checks >= recurrence_target and recurred: false: set status: validated
  6. Update effectiveness field 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}}

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.