▋
agent/dir-rule/SKILL.md

name: dir-rule description: >- Add a directory-scoped rule to the nearest nested CLAUDE.md or AGENTS.md cleanly. The directory-level counterpart to /rule and /r-rule. Invoke manually as /dir-rule .

dir-rule

Manually-invoked skill. The user runs /dir-rule <new rule in their words> to fold a standing instruction into the agent-instructions file for the relevant directory or subtree, keeping narrower rules out of repo-root/global context.

When to use this

  • The user types /dir-rule ... or asks to add a rule for a folder, subtree, package, app area, or nested CLAUDE.md / AGENTS.md.
  • Use dir-rule when the instruction should apply only below a directory, not across the whole repo or workspace.
  • Do NOT use this for the user's top-level personal instructions; use /rule.
  • Do NOT use this for a repo-wide instruction at the repository root; use /r-rule.

Locate the target

  1. Identify the intended directory from the user's wording, current working directory, branch/worktree context, or files being discussed.
  2. Walk upward from that directory toward the repo/workspace root and find the closest CLAUDE.md or AGENTS.md that is still inside the intended subtree. Prefer an existing nested file over creating a new one.
  3. If both CLAUDE.md and AGENTS.md exist in the same directory, prefer the file that already holds similar guidance. If unclear, prefer CLAUDE.md and mention the sibling file in the report.
  4. If no nested instruction file exists and the rule is clearly directory-local, create CLAUDE.md in the narrowest directory that should own it.
  5. If the rule actually belongs at repo root or user level, stop and route to /r-rule or /rule instead of creating a needless nested file.

Workflow

  1. Read the whole target file first. You must see every section to place the rule well, avoid duplication, and preserve local conventions.
  2. Decide placement. Merge the new rule into an existing section or bullet when it sharpens current guidance. Add a new section only for a genuinely new theme.
  3. Integrate, don't paste. Rewrite the user's phrasing into the target file's voice and scope. Keep it concise and imperative.
  4. Keep scope explicit. If the directory file could be read out of context, name the owning subtree or package in the heading or first bullet.
  5. Condense while editing. Collapse overlapping nearby guidance and remove filler without deleting actual rule substance.
  6. Avoid instruction drift. If the new nested rule narrows or overrides a broader repo/global rule, phrase the relationship clearly instead of leaving the files contradictory.
  7. Show the diff and explain. Report the directory target, the file edited or created, where the rule landed, and anything merged or condensed.
  8. Don't commit. Leave the change in the working tree for the user to review.

Judgement notes

  • Bias toward the narrowest file that matches the requested scope, but do not create a nested instruction file for one-off trivia or a rule that belongs in an existing repo-root section.
  • Directory rules should carry local facts and local behavioral defaults, not restatements of global engineering style.
  • If no safe target can be inferred, ask one concise question rather than guessing and scattering instructions.