forge-behavior
Skill8 starsChanged 7 months agoMITView on GitHub
Manage dotforge v3 behavior governance — view status, toggle behaviors, adjust strictness. Use when the user asks about active behaviors, wants to disable one for the current session, or adjust escalation thresholds.
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
- init-projectSkill
- learn-projectSkill
- mcp-addSkill
- plugin-generatorSkill
- reset-projectSkill
- rule-effectivenessSkill
- scout-reposSkill
- session-insightsSkill
- sync-all-reposSkill
- sync-templateSkill
- update-practicesSkill
- watch-upstreamSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 23
Do NOT invoke this skill for v2.9 configuration tasks (use /forge audit, /forge sync, etc.) or for behaviors that have not yet been …
- Very specific: line 44
After changing, recompile the behavior with scripts/compiler/compile.sh behaviors/<id>/behavior.yaml <output_dir> and restart Claude Code …
≈ “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
/forge behavior
Thin wrapper around scripts/forge-behavior/cli.sh. Dispatches behavior
governance actions. This skill is part of dotforge v3 (Phase 1 of behavior
governance) and should only be used inside dotforge itself or projects that
have adopted v3 — not on v2.9 projects.
When to use
Invoke this skill when the user asks any of:
- "What behaviors are active?"
- "What's the counter on search-first?"
- "Disable search-first for this session"
- "Turn off the nudge on writes"
- "Make search-first stricter / more relaxed"
Do NOT invoke this skill for v2.9 configuration tasks (use /forge audit,
/forge sync, etc.) or for behaviors that have not yet been catalogued
(Phase 1 only ships search-first).
Actions
scripts/forge-behavior/cli.sh status [--session SESSION_ID]
scripts/forge-behavior/cli.sh on <behavior_id> [--project | --session SESSION_ID]
scripts/forge-behavior/cli.sh off <behavior_id> [--project | --session SESSION_ID]
scripts/forge-behavior/cli.sh strict <behavior_id>
scripts/forge-behavior/cli.sh relaxed <behavior_id>status — Print the current catalogue (behaviors/index.yaml) plus a
per-session summary from .forge/runtime/state.json: counters, effective
levels, override counts, pending_block status, and any session-scope
overrides.
on / off — Toggle a behavior's active state.
--project(default): mutatesbehaviors/index.yaml. Persistent. After changing, recompile the behavior withscripts/compiler/compile.sh behaviors/<id>/behavior.yaml <output_dir>and restart Claude Code so the new hook registration takes effect.--session SESSION_ID: mutates only.forge/runtime/state.json'sbehavior_overrides[]for that session. The compiled hook short-circuits silently when disabled. No recompile needed. Effect lasts until the session is purged by TTL.
strict / relaxed — Mutate behaviors/<id>/behavior.yaml escalation:
strict: halves eachafterthreshold, minimum 1. Makes violations escalate sooner.relaxed: doubles eachafterthreshold. Makes violations escalate later.- Both project-scope only in v1. Session-scope strictness deferred to
Phase 2 — the runtime would need to pass a strictness multiplier into
forge_resolve_level, which v1 does not support.
Preconditions
jqmust be installed (runtime requirement).python3withpyyamlmust be installed (YAML reading/writing).- The project must already have
behaviors/index.yaml. If missing, create one withbehaviors: []and populate viaon <id>.
Scope matrix
| Action | --project | --session |
| status | always shown | filters to one session |
| on / off | mutates index.yaml | writes to state.json |
| strict | mutates yaml | (not implemented v1) |
| relaxed | mutates yaml | (not implemented v1) |
Example flows
Check what is active right now:
/forge behavior statusSilence search-first for a noisy debugging session:
/forge behavior off search-first --session <session_id>Tighten up for strict development mode:
/forge behavior strict search-first
# then recompile and restartNotes
- The CLI honors
FORGE_BEHAVIORS_DIRas an override ofbehaviors/location — useful for tests and isolated environments. - Direct tool result for tests:
scripts/forge-behavior/tests/run_all.sh.
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.

