メニュー
Create, validate, or place behavioral rules in forge modules. USE WHEN create rule, new rule, write rule, capture rule, add a rule, graduate a correction or convention to a rule, validate rule, rule conventions, where does this rule belong, or the user runs /Rule.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | BuildRule |
| version | 0.1.0 |
| description | Create, validate, or place behavioral rules in forge modules. USE WHEN create rule, new rule, write rule, capture rule, add a rule, graduate a correction or convention to a rule, validate rule, rule conventions, where does this rule belong, or the user runs /Rule. |
Author, place, and validate the small always-in-context instruction files that steer every session. A rule is the durable form of a correction: when the user says "always do X" or "never do Y again", it becomes a rule, not a memory.
A rule is a single .md file in the owning module's rules/ directory. One file, one behavior — when something goes wrong, the filename names the rule that caused it. The only valid subdirectories are locale (rules/cs-CZ/), harness and model qualifiers (rules/claude/, rules/claude/claude-opus-4-6/), and gitignored user/ overrides; resolution precedence is in PROV-0005.
PascalCase, scope + focus, self-explanatory in English: PreferTrash, VerifyClaims, NoEmDash. No spaces, hyphens, or opaque acronyms. The filename is the rule's identity in every error report.
Optional. When present: name, version, description, targets (harness filter), mode (replace | append | prepend, qualifier variants only). Assembly strips frontmatter at deploy — never put load-bearing content there.
Concise, actionable prose stating the current truth (PresentTense; no backstory). A wrong/right example pair beats three paragraphs of explanation. No headings needed; max depth 3 if used. Cite sources for factual claims (CiteSources).
Every word costs tokens on every interaction — rules are always in context. If the model already does it unprompted, the rule belongs in a model qualifier directory or nowhere (see OptimizeContext). If it needs more than ~20 lines, it is probably a skill, not a rule.
Rules are authored in the owning module's rules/, never directly in ~/.claude/ (AuthorInModules — deployed files get overwritten on install). Route by subject: version-control behavior → the module owning VersionControl; vault conventions → forge-obsidian; no clear owner → forge-steering. Prefer folding a new constraint into an existing rule on the same subject over creating a near-duplicate file (LessIsMore).
grep -l <topic> */rules/*.md across modules; extend an existing rule if one covers the subject.make install from the module (or mirror the edit into the deployed ~/.claude/rules/ copy for immediate effect in the current session)..md file in rules/ (or a valid qualifier subdirectory)Report COMPLIANT or NON-COMPLIANT with specific fixes.
Create and validate skills for forge modules. USE WHEN create skill, new skill, write skill, validate skill, check skill, skill structure, skill conventions.
Create, validate, evaluate, and iterate skills for forge modules. USE WHEN create skill, new skill, write skill, validate skill, check skill, skill structure, skill conventions, test a skill, run skill evals, benchmark a skill, skill not triggering, optimize skill description. Not for adopting community skills (AdoptArtifact) or shipping artifacts downstream (PublishArtifact).
Scaffold a workshop project: a VCS spine (git + jj colocate + entire + forge hooks), the private/public/assets flow layout with a .tlp manifest, a .claude/ that mounts the knowledge vault, and on-demand satellites (vault folder-note, data dir, private remote). USE WHEN starting a new project, initializing a folder for work, adding a vault note or data dir or remote to a project, archiving a project, or the user runs `project` / `atlas`.
Collaborative ideation before implementation — explore context, clarify intent, propose approaches. USE WHEN starting creative work, new features, design decisions, or modifying behavior.
Write a formal design spec from brainstorming output or requirements. USE WHEN design approved, write spec, formalize design, spec document.
Execute an implementation plan inline — task by task in a single session — then finish the work: verify, present integration options (merge, PR, keep, discard), and clean up the workspace. USE WHEN executing plan, run plan, implement plan, inline execution, implementation complete, deciding merge strategy, finishing a feature branch or workspace.