hiroro-work/claude-plugins/apply-rules

Apply Rules

Usage

/apply-rules <source>                  # Apply from GitHub URL or local path
/apply-rules                           # Apply using config file
/apply-rules --config <path>           # Apply using specified config file
/apply-rules --dry-run                 # Show what would change without writing
/apply-rules --dry-run <source>        # Dry run with specified source

<source> points directly to the rules directory (merge-rules or extract-rules output):

• GitHub: https://github.com/org/repo/tree/main/.claude/rules
• Local: ~/org-rules/.claude/rules

Configuration

Config file search order:

1. --config <path> argument
2. .claude/apply-rules.local.md (project-level)
3. ~/.claude/apply-rules.local.md (user-level)

File format: YAML frontmatter only (no markdown body).

---
# Rules directory (GitHub URL or local path)
# GitHub: https://github.com/org/repo/tree/main/.claude/rules
# Local: ~/org-rules/.claude/rules
source: https://github.com/org/repo/tree/main/.claude/rules
 
# Alternative: specify GitHub source components separately
# (useful when branch name contains "/" or for tags/SHAs)
# source_repo: org/repo
# source_ref: feature/rules-v2
# source_path: .claude/rules
 
# Output directory in target project (default: .claude/rules)
# Examples go to the sibling <output_dir>-extras (.claude/rules-extras)
output_dir: .claude/rules
 
# Auto-detect which rules to apply (default: true)
# When false, applies ALL rules from source
auto_detect: true
 
# Explicitly include rules even if not auto-detected
include: []
# Example: [languages/typescript, integrations/rails-inertia]
 
# Explicitly exclude rules even if auto-detected
exclude: []
# Example: [frameworks/rails-views]
 
# Report language (default: ja)
language: ja
---

CLI argument <source> overrides the config's source field.

Examples directory (no configuration key). .examples.md files live in a sibling of the rules directory: that path with any trailing / removed and -extras appended — <output_dir>-extras in the target project, <source>-extras on the source side, .claude/rules-extras/ under the default output_dir. Reading takes each rule file's examples from the derived directory first and from the rule file's own directory only when that misses, so a pre-split layout — examples still beside the rule files — is still picked up; writing always targets the derived directory. apply-rules does not read extract-rules' examples_output_dir.

Processing Flow

Step 1: Load Configuration

1. If CLI <source> argument provided, use it (overrides config source)
2. Search for config file (see search order above)
3. Parse YAML frontmatter, apply defaults for omitted fields

• `language` resolution order: Skill config → Claude Code settings (~/.claude/settings.json → language field) → default ja

1. Validate:

• source must be specified (via CLI argument or config file)
• If neither: Error "No source specified. Provide a GitHub URL or local path as argument, or create .claude/apply-rules.local.md with a source: field."

Step 2: Fetch Source Rules

If source is a local path:

1. Expand ~ and resolve to absolute path
2. Verify directory exists and contains rule files (.md)
3. Read directly from this location

If source is a GitHub URL:

Parse URL to extract owner, repo, branch, and path:

• https://github.com/{owner}/{repo}/tree/{branch}/{path}
• Example: https://github.com/org/repo/tree/main/.claude/rules

→ owner: org, repo: repo, branch: main, path: .claude/rules

Note on ambiguous refs: Branch names may contain / (e.g., feature/rules-v2), and refs can also be tags or SHAs:

• Try ref candidates from the longest prefix first: gh api repos/{owner}/{repo}/git/ref/heads/{candidate}, then gh api repos/{owner}/{repo}/git/ref/tags/{candidate}; for a SHA-shaped candidate use gh api repos/{owner}/{repo}/commits/{candidate}
• A successful response is a match: stop there, use the candidate as {branch} and the remaining segments as {path}. A 404 (git/ref) or 422 (commits) means no match — try the next shorter prefix. Any other error, or no candidate matching, stops with an error suggesting source_repo / source_ref / source_path
• Alternatively, the user can specify components separately in the config:

``yaml source_repo: org/repo source_ref: feature/rules-v2 source_path: .claude/rules `` When these fields are present, they take precedence over URL parsing.

• For the common case (branch = main or master), simple URL parsing works.

Fetch using gh api:

1. Verify authentication: gh auth status
2. Create temp directory: mktemp -d
3. List top-level directory contents:

`` gh api repos/{owner}/{repo}/contents/{path}?ref={branch} ` For each entry with type: "dir", recursively fetch subdirectory contents: ` gh api repos/{owner}/{repo}/contents/{path}/{subdir}?ref={branch} ` This dynamically discovers all categories (not limited to languages/, frameworks/, integrations/`).

1. For each .md file found, fetch content and decode:

`` gh api repos/{owner}/{repo}/contents/{file_path}?ref={branch} --jq '.content | @base64d' ` Save under <tmpdir>/rules/, preserving the directory structure below {path}`

1. Repeat items 3-4 (the recursive directory listing and the per-file content fetch) for {path}-extras, saving under <tmpdir>/rules-extras/. A 404 on the listing means this source keeps no separate examples directory — skip it silently. <source> for the rest of this Step is <tmpdir>/rules, so <source>-extras resolves to <tmpdir>/rules-extras
2. Temp dir is cleaned up in Step 8 (Cleanup)

Inventory source files:

• Glob for **/*.md under <source> — the result includes any .examples.md a pre-split source kept beside its rule files
• Glob for **/*.examples.md under <source>-extras. A missing <source>-extras is the normal pre-split case: treat it as an empty listing rather than an error
• A rule file's examples are the <name>.examples.md at the same relative sub-path, with <source>-extras winning over a co-located copy from the first glob
• Skip project.md and project.examples.md (inherently project-specific)
• Skip .local.md files (merge-rules output should not contain these, but handle gracefully)
• Parse each file: extract YAML frontmatter (paths:) and body sections

Step 3: Detect Target Project Tech Stack

Analyze the current working directory to determine which source rules are relevant. Detection is best-effort, based on dependency files (e.g., Gemfile, package.json) and project directory structure (e.g., app/controllers/).

Read references/detection-heuristics.md for the full detection table mapping indicators to rule files. If the source contains rule files not covered in the table, use AI judgment to match them against the project's dependencies and file structure.

Apply overrides:

• Add include: entries to the detected set
• Remove exclude: entries from the detected set
• If auto_detect: false: start with ALL source rules, then apply exclude only

Step 4: Filter and Propose

If `auto_detect: false`: Apply ALL source rules (minus exclude entries). Skip the proposal step entirely — no integration proposals or skipped rules. Proceed directly to Step 5.

If `auto_detect: true` (default):

1. Auto-matched rules: Rules that match detected tech stack → apply automatically
2. Integration proposals: For integrations NOT detected in the project but related to a detected framework (e.g., source has integrations/rails-pundit but project doesn't use pundit), use AskUserQuestion to present them as a single list:

> The following integration rules are available in the source but were not detected in your project. Which would you like to apply? > 1. integrations/rails-pundit — Authorization library Pundit rules > 2. integrations/rails-good-job — Job queue GoodJob rules > > Options: all / none / specify by number (e.g. "1" or "1,2")

Apply only those the user approves.

1. Skipped rules: Rules for tech not detected and not in related frameworks → skip, list in report

Step 5: Inventory Existing Target Rules

1. Check if {output_dir}/ exists in the target project
2. If exists, list {output_dir}/**/*.md — which includes any co-located .examples.md — and <output_dir>-extras/**/*.examples.md. A missing <output_dir>-extras is the normal pre-split case: treat it as an empty listing rather than an error
3. Read each rule file (the .md and .local.md entries of the first listing) and resolve its examples per § Configuration's "Examples directory (no configuration key)" paragraph: the <name>.examples.md at the same relative sub-path, with a trailing .local dropped from the rule file's basename (languages/ruby.local.md → languages/ruby.examples.md). Read each resolved examples file once — a .md and its .local.md resolve to the same one. Every later step reads target examples through this resolution
4. Parse frontmatter and body sections for each
5. Categorize files the same way as source files
6. Detect hybrid format: If any target .md file contains ## Project-specific patterns (hybrid format from extract-rules split_output: false), note this. The merge step will convert hybrid to split format

Step 5.5: Normalize File Names

Before merging, align target file names with source (canonical) names.

1. Compare target file names against source file names within the same category
2. Detect naming variants: singular/plural (controller/controllers), minor differences for the same concept
3. If renames are detected, use AskUserQuestion to confirm:

> The following target files will be renamed to match source (canonical) names: > 1. frameworks/rails-controller.md → frameworks/rails-controllers.md > > Options: all / none / specify by number

1. Apply approved renames and report in the summary

Step 6: Merge Rules

For each filtered source rule file, determine the merge action:

6a. Merge `.md` files (Principles):

Case: No existing `.md`

1. Copy source .md as-is (source from merge-rules contains only ## Principles)

Case: Existing `.md` exists

1. `paths:` frontmatter: Union of all path patterns, deduplicate
2. Hybrid → split conversion: If existing .md contains ## Project-specific patterns (hybrid format):

• Extract that section and move to .local.md (create if not exists, append if exists)
• Remove the section from .md, keeping only ## Principles

1. `## Principles`:

• Match principles by name (text before parenthetical hints)
• Source principle not in target → Add
• Target principle not in source → Keep (project may have added its own)
• Same principle, same meaning but different hints → Union hints from both
• Same principle name but different content → Collect all conflicts, then use AskUserQuestion to present them together:

> The following principles differ between org rules and project rules: > > 1. Immutability (in languages/ruby.md) > - Org: Immutability (spread, map/filter/reduce, const) > - Project: Immutability (freeze, deep clone, readonly) > > 2. Error handling (in frameworks/rails.md) > - Org: Error handling (rescue, custom exceptions) > - Project: Error handling (rescue, retry, circuit breaker) > > For each, choose: (a) Adopt org rule / (b) Keep project rule / (c) Keep both > Example: "1a, 2c" or "all a"

6b. Clean up promoted patterns from `.local.md` files: