codeply-cli 0.5.6 → 0.6.0

package/skills/hookify-rules/SKILL.md

@@ -1,128 +1,128 @@
----
-name: hookify-rules
-description: This skill should be used when the user asks to create a hookify rule, write a hook rule, configure hookify, add a hookify rule, or needs guidance on hookify rule syntax and patterns.
----
-
-# Writing Hookify Rules
-
-## Overview
-
-Hookify rules are markdown files with YAML frontmatter that define patterns to watch for and messages to show when those patterns match. Rules are stored in `.claude/hookify.{rule-name}.local.md` files.
-
-## Rule File Format
-
-### Basic Structure
-
-```markdown
----
-name: rule-identifier
-enabled: true
-event: bash|file|stop|prompt|all
-pattern: regex-pattern-here
----
-
-Message to show Claude when this rule triggers.
-Can include markdown formatting, warnings, suggestions, etc.
-```
-
-### Frontmatter Fields
-
-| Field | Required | Values | Description |
-|-------|----------|--------|-------------|
-| name | Yes | kebab-case string | Unique identifier (verb-first: warn-*, block-*, require-*) |
-| enabled | Yes | true/false | Toggle without deleting |
-| event | Yes | bash/file/stop/prompt/all | Which hook event triggers this |
-| action | No | warn/block | warn (default) shows message; block prevents operation |
-| pattern | Yes* | regex string | Pattern to match (*or use conditions for complex rules) |
-
-### Advanced Format (Multiple Conditions)
-
-```markdown
----
-name: warn-env-api-keys
-enabled: true
-event: file
-conditions:
-  - field: file_path
-    operator: regex_match
-    pattern: \.env$
-  - field: new_text
-    operator: contains
-    pattern: API_KEY
----
-
-You're adding an API key to a .env file. Ensure this file is in .gitignore!
-```
-
-**Condition fields by event:**
-- bash: `command`
-- file: `file_path`, `new_text`, `old_text`, `content`
-- prompt: `user_prompt`
-
-**Operators:** `regex_match`, `contains`, `equals`, `not_contains`, `starts_with`, `ends_with`
-
-All conditions must match for rule to trigger.
-
-## Event Type Guide
-
-### bash Events
-Match Bash command patterns:
-- Dangerous commands: `rm\s+-rf`, `dd\s+if=`, `mkfs`
-- Privilege escalation: `sudo\s+`, `su\s+`
-- Permission issues: `chmod\s+777`
-
-### file Events
-Match Edit/Write/MultiEdit operations:
-- Debug code: `console\.log\(`, `debugger`
-- Security risks: `eval\(`, `innerHTML\s*=`
-- Sensitive files: `\.env$`, `credentials`, `\.pem$`
-
-### stop Events
-Completion checks and reminders. Pattern `.*` matches always.
-
-### prompt Events
-Match user prompt content for workflow enforcement.
-
-## Pattern Writing Tips
-
-### Regex Basics
-- Escape special chars: `.` to `\.`, `(` to `\(`
-- `\s` whitespace, `\d` digit, `\w` word char
-- `+` one or more, `*` zero or more, `?` optional
-- `|` OR operator
-
-### Common Pitfalls
-- **Too broad**: `log` matches "login", "dialog" — use `console\.log\(`
-- **Too specific**: `rm -rf /tmp` — use `rm\s+-rf`
-- **YAML escaping**: Use unquoted patterns; quoted strings need `\\s`
-
-### Testing
-```bash
-python3 -c "import re; print(re.search(r'your_pattern', 'test text'))"
-```
-
-## File Organization
-
-- **Location**: `.claude/` directory in project root
-- **Naming**: `.claude/hookify.{descriptive-name}.local.md`
-- **Gitignore**: Add `.claude/*.local.md` to `.gitignore`
-
-## Commands
-
-- `/hookify [description]` - Create new rules (auto-analyzes conversation if no args)
-- `/hookify-list` - View all rules in table format
-- `/hookify-configure` - Toggle rules on/off interactively
-- `/hookify-help` - Full documentation
-
-## Quick Reference
-
-Minimum viable rule:
-```markdown
----
-name: my-rule
-enabled: true
-event: bash
-pattern: dangerous_command
----
-Warning message here
-```
+---
+name: hookify-rules
+description: This skill should be used when the user asks to create a hookify rule, write a hook rule, configure hookify, add a hookify rule, or needs guidance on hookify rule syntax and patterns.
+---
+
+# Writing Hookify Rules
+
+## Overview
+
+Hookify rules are markdown files with YAML frontmatter that define patterns to watch for and messages to show when those patterns match. Rules are stored in `.claude/hookify.{rule-name}.local.md` files.
+
+## Rule File Format
+
+### Basic Structure
+
+```markdown
+---
+name: rule-identifier
+enabled: true
+event: bash|file|stop|prompt|all
+pattern: regex-pattern-here
+---
+
+Message to show Claude when this rule triggers.
+Can include markdown formatting, warnings, suggestions, etc.
+```
+
+### Frontmatter Fields
+
+| Field | Required | Values | Description |
+|-------|----------|--------|-------------|
+| name | Yes | kebab-case string | Unique identifier (verb-first: warn-*, block-*, require-*) |
+| enabled | Yes | true/false | Toggle without deleting |
+| event | Yes | bash/file/stop/prompt/all | Which hook event triggers this |
+| action | No | warn/block | warn (default) shows message; block prevents operation |
+| pattern | Yes* | regex string | Pattern to match (*or use conditions for complex rules) |
+
+### Advanced Format (Multiple Conditions)
+
+```markdown
+---
+name: warn-env-api-keys
+enabled: true
+event: file
+conditions:
+  - field: file_path
+    operator: regex_match
+    pattern: \.env$
+  - field: new_text
+    operator: contains
+    pattern: API_KEY
+---
+
+You're adding an API key to a .env file. Ensure this file is in .gitignore!
+```
+
+**Condition fields by event:**
+- bash: `command`
+- file: `file_path`, `new_text`, `old_text`, `content`
+- prompt: `user_prompt`
+
+**Operators:** `regex_match`, `contains`, `equals`, `not_contains`, `starts_with`, `ends_with`
+
+All conditions must match for rule to trigger.
+
+## Event Type Guide
+
+### bash Events
+Match Bash command patterns:
+- Dangerous commands: `rm\s+-rf`, `dd\s+if=`, `mkfs`
+- Privilege escalation: `sudo\s+`, `su\s+`
+- Permission issues: `chmod\s+777`
+
+### file Events
+Match Edit/Write/MultiEdit operations:
+- Debug code: `console\.log\(`, `debugger`
+- Security risks: `eval\(`, `innerHTML\s*=`
+- Sensitive files: `\.env$`, `credentials`, `\.pem$`
+
+### stop Events
+Completion checks and reminders. Pattern `.*` matches always.
+
+### prompt Events
+Match user prompt content for workflow enforcement.
+
+## Pattern Writing Tips
+
+### Regex Basics
+- Escape special chars: `.` to `\.`, `(` to `\(`
+- `\s` whitespace, `\d` digit, `\w` word char
+- `+` one or more, `*` zero or more, `?` optional
+- `|` OR operator
+
+### Common Pitfalls
+- **Too broad**: `log` matches "login", "dialog" — use `console\.log\(`
+- **Too specific**: `rm -rf /tmp` — use `rm\s+-rf`
+- **YAML escaping**: Use unquoted patterns; quoted strings need `\\s`
+
+### Testing
+```bash
+python3 -c "import re; print(re.search(r'your_pattern', 'test text'))"
+```
+
+## File Organization
+
+- **Location**: `.claude/` directory in project root
+- **Naming**: `.claude/hookify.{descriptive-name}.local.md`
+- **Gitignore**: Add `.claude/*.local.md` to `.gitignore`
+
+## Commands
+
+- `/hookify [description]` - Create new rules (auto-analyzes conversation if no args)
+- `/hookify-list` - View all rules in table format
+- `/hookify-configure` - Toggle rules on/off interactively
+- `/hookify-help` - Full documentation
+
+## Quick Reference
+
+Minimum viable rule:
+```markdown
+---
+name: my-rule
+enabled: true
+event: bash
+pattern: dangerous_command
+---
+Warning message here
+```

package/skills/inherit-legacy-style/SKILL.md

@@ -1,157 +1,157 @@
----
-name: inherit-legacy-style
-description: Legacy-project style inheritance skill. Use when the user types /inherit-legacy-style, or when onboarding an AI coding agent onto a hand-written legacy project and you need to prevent "style drift" (the model imposing its pretrained mainstream idioms onto the project). Language- and framework-agnostic — it aligns meta-architecture only, not syntax. Once run, it becomes a behavioral constraint on all subsequent coding tasks. Do NOT use for pure research or one-off questions unrelated to code-style alignment.
-metadata:
-  origin: community
-allowed-tools: Read, Glob, Grep, Bash, Edit, Write, AskUserQuestion
----
-
-# Inherit Legacy Style
-
-Prevents AI code style drift in legacy projects by scanning the codebase for implicit conventions across 4 meta-architecture dimensions, resolving conflicts with the user one at a time, and crystallizing the consensus into an enforceable `.ai-style-rules.md`. Fully language- and framework-agnostic.
-
-## When to Activate
-
-- User types `/inherit-legacy-style`
-- User mentions onboarding AI onto a hand-written legacy project
-- User is worried about AI-generated code "drifting" from existing project conventions
-- User wants to extract and codify their project's implicit coding rules
-
-## When to Use
-
-Use this skill when you need to preserve legacy project style and prevent AI-generated style drift. See **When to Activate** above for trigger conditions.
-
-## Prerequisites
-
-- Git (recommended; non-Git projects fall back to file timestamps for incremental mode)
-- Read/Write access to the project root (generates `.ai-style-rules.md` and optionally `CLAUDE.md`)
-
-## Workflow
-
-### Step 0 — Auto-Detect Mode
-
-Silently check for `.ai-style-rules.md` at the project root:
-
-| File exists? | Mode |
-|---|---|
-| No | **Branch A — First-time Full-Scan** |
-| Yes | **Branch B — Incremental Sniff** |
-
-Announce the mode in one line and proceed — never ask the user to pick.
-
-### Branch A — First-time Full-Scan
-
-**1. Measure scale, pick a scanning tier**
-
-```bash
-git ls-files | grep -cE '\.(js|ts|jsx|tsx|vue|py|go|rs|java|kt|rb|php|cs|swift|c|cpp|h)$'
-```
-
-| Tier | Source files | Strategy |
-|---|---|---|
-| Small | ≲ 50 | Full close-read every source |
-| Medium | 50–500 | Infra layer = full read; business layer = sample 2–3 per dimension |
-| Large | ≳ 500 | Strict sampling + budget cap; `--stat` summary first, then targeted reads |
-
-**2. Scan along 4 dimensions**
-
-1. **File Anatomy** — in-file declaration order (imports → types → main logic → helpers → export)
-2. **State & Control Flow** — naming conventions for async state, pagination, flags
-3. **Infrastructure** — where cross-cutting utils live (interceptors, formatters, middleware)
-4. **Error Handling** — try/catch vs global interceptor vs Result return; null-check habits
-
-**3. Apply signal-threshold noise reduction**
-
-Before interrupting the user, evaluate signal strength:
-
-- **Weak signal** → auto-suppress: minority <5% AND count <10 → majority wins, minority goes to DONTs
-- **Strong signal** → grill: near-even split, or semantic fork on a core dimension
-- **Small-project exception**: sources ≲50, "3 vs 2" is NOT a majority → grill it
-
-**4. Resolve conflicts one at a time (Grilling Protocol)**
-
-For each strong-signal conflict, present exactly ONE question with 4 options:
-
-> Evidence: `pathA` uses style X, `pathB` uses style Y
-> WARNING: Risk: mixing both fractures the project style
-> Choose: `1` follow X  `2` follow Y  `3` this is evolution, update rules  `4` I have a new rule
-
-Suspend until the user answers, then proceed to the next conflict. Never stack questions.
-
-**5. Generate `.ai-style-rules.md`** with three mandatory sections:
-- **[Golden Files]** — real exemplar paths annotated with what they demonstrate
-- **[Naming & State-Control Rules]** — concrete, checkable conventions
-- **[DONTs]** — anti-patterns that must not propagate
-
-**6. Install the persistent hook**
-
-Ask the user for enforcement strength (use `AskUserQuestion`):
-
-| Option | Mechanism |
-|---|---|
-| **1** Soft hook (recommended) | Write `@.ai-style-rules.md` reference into project `CLAUDE.md` |
-| **2** Hard hook | Soft hook + `PreToolUse[Write\|Edit\|MultiEdit]` Hook in `settings.json` |
-| **3** No hook | Keep the rules file; user references manually |
-
-### Branch B — Incremental Sniff
-
-1. Read existing `.ai-style-rules.md`; if it has a commit fingerprint, `git diff <last_hash> HEAD --stat` to pinpoint delta
-2. Read recent Git changes (`git log -3 --stat` → inspect suspect files on demand)
-3. For oversized diffs (>hundreds of files): `--stat` summary only + sample the largest changes
-4. Compare new code against recorded rules → conflicts go through Grilling Protocol
-5. Append evolution log at the end of `.ai-style-rules.md` (never overwrite old rules)
-
-### Per-Turn Enforcement
-
-When `.ai-style-rules.md` is in context (loaded via CLAUDE.md), every code-writing task must open with a **compliance declaration** in the reasoning chain, naming the exemplar being followed and the DONTs being avoided.
-
-## How It Works
-
-This skill auto-detects whether it's a first-time or incremental run via `.ai-style-rules.md` presence:
-
-- **First-time (Branch A)** — Measures project scale, scans codebase across 4 meta-architecture dimensions (File Anatomy, State & Control Flow, Infrastructure, Error Handling), applies signal-threshold noise reduction to suppress weak conflicts, resolves strong-signal conflicts one-at-a-time with the user, generates `.ai-style-rules.md` with Golden Files / Naming Rules / DONTs, and offers optional enforcement hooks.
-- **Incremental (Branch B)** — Reads existing rules, checks recent Git diffs for new or conflicting patterns, runs the same one-at-a-time grilling protocol for any conflicts found, and appends evolution logs without overwriting existing rules.
-- **Per-Turn Enforcement** — When hooked via `CLAUDE.md`, every code-writing task opens with a compliance declaration naming the exemplar followed and the DONTs avoided.
-
-## Output Specification
-
-- `.ai-style-rules.md` at project root (with commit fingerprint + scale tier in header)
-- Optionally `CLAUDE.md` with `@.ai-style-rules.md` reference
-- Evolution logs appended as `### [YYYY-MM-DD] Style Evolution Log` entries
-
-## Anti-Patterns
-
-- FAIL: Do NOT skip the scale measurement step — sampling a 30-file project "starves" it; full-scanning a 5,000-file repo blows up
-- FAIL: Do NOT stack multiple conflict questions at once — grilling is strictly one-at-a-time
-- FAIL: Do NOT overwrite old rules in incremental mode — always append evolution logs
-- FAIL: Do NOT default to "hard hook" without asking — enforcement strength is the user's call
-- FAIL: Do NOT judge syntax or tech-stack quality — this skill aligns meta-architecture only
-- FAIL: Do NOT copy bugs from exemplar files — reuse structure, flag defects
-
-## Best Practices
-
-- Announce the detected mode (first-time vs incremental) and scale tier in one line before scanning
-- For large projects, read `--stat` summaries first, then targeted `Read` on suspect files
-- Let the signal threshold handle noise — a 843-vs-8 naming split should auto-resolve without user interruption
-- When in doubt about signal strength, lean toward asking
-- The CLAUDE.md soft hook (`@.ai-style-rules.md`) is usually sufficient; hard hook only if the user wants mechanical enforcement
-
-## Related Skills
-
-- `init` — initialize a new CLAUDE.md with codebase documentation
-- `code-review` — review diffs for correctness and style issues
-- `simplify` — review code for reuse and simplification opportunities
-
-## Examples
-
-1. **First-time onboarding**
-   - User: "Help me onboard AI to this older codebase without changing its style."
-   - Action: Run Branch A full-scan → measure scale → scan 4 dimensions → grill conflicts → generate `.ai-style-rules.md` → offer hook strength (soft/hard/none).
-
-2. **Incremental update after team changes**
-   - User: "We added a new module; keep existing style rules intact."
-   - Action: Run Branch B incremental sniff → compare Git deltas to recorded rules → grill any new conflicts → append evolution log without overwriting.
-
-3. **Enforcing DONTs via CLAUDE.md**
-   - User: "Make sure all new code stays consistent with the project's rules."
-   - Action: Soft hook installed → `.ai-style-rules.md` auto-loaded every session → every code-writing task opens with compliance declaration, reusing exemplar patterns and avoiding DONTs.
+---
+name: inherit-legacy-style
+description: Legacy-project style inheritance skill. Use when the user types /inherit-legacy-style, or when onboarding an AI coding agent onto a hand-written legacy project and you need to prevent "style drift" (the model imposing its pretrained mainstream idioms onto the project). Language- and framework-agnostic — it aligns meta-architecture only, not syntax. Once run, it becomes a behavioral constraint on all subsequent coding tasks. Do NOT use for pure research or one-off questions unrelated to code-style alignment.
+metadata:
+  origin: community
+allowed-tools: Read, Glob, Grep, Bash, Edit, Write, AskUserQuestion
+---
+
+# Inherit Legacy Style
+
+Prevents AI code style drift in legacy projects by scanning the codebase for implicit conventions across 4 meta-architecture dimensions, resolving conflicts with the user one at a time, and crystallizing the consensus into an enforceable `.ai-style-rules.md`. Fully language- and framework-agnostic.
+
+## When to Activate
+
+- User types `/inherit-legacy-style`
+- User mentions onboarding AI onto a hand-written legacy project
+- User is worried about AI-generated code "drifting" from existing project conventions
+- User wants to extract and codify their project's implicit coding rules
+
+## When to Use
+
+Use this skill when you need to preserve legacy project style and prevent AI-generated style drift. See **When to Activate** above for trigger conditions.
+
+## Prerequisites
+
+- Git (recommended; non-Git projects fall back to file timestamps for incremental mode)
+- Read/Write access to the project root (generates `.ai-style-rules.md` and optionally `CLAUDE.md`)
+
+## Workflow
+
+### Step 0 — Auto-Detect Mode
+
+Silently check for `.ai-style-rules.md` at the project root:
+
+| File exists? | Mode |
+|---|---|
+| No | **Branch A — First-time Full-Scan** |
+| Yes | **Branch B — Incremental Sniff** |
+
+Announce the mode in one line and proceed — never ask the user to pick.
+
+### Branch A — First-time Full-Scan
+
+**1. Measure scale, pick a scanning tier**
+
+```bash
+git ls-files | grep -cE '\.(js|ts|jsx|tsx|vue|py|go|rs|java|kt|rb|php|cs|swift|c|cpp|h)$'
+```
+
+| Tier | Source files | Strategy |
+|---|---|---|
+| Small | ≲ 50 | Full close-read every source |
+| Medium | 50–500 | Infra layer = full read; business layer = sample 2–3 per dimension |
+| Large | ≳ 500 | Strict sampling + budget cap; `--stat` summary first, then targeted reads |
+
+**2. Scan along 4 dimensions**
+
+1. **File Anatomy** — in-file declaration order (imports → types → main logic → helpers → export)
+2. **State & Control Flow** — naming conventions for async state, pagination, flags
+3. **Infrastructure** — where cross-cutting utils live (interceptors, formatters, middleware)
+4. **Error Handling** — try/catch vs global interceptor vs Result return; null-check habits
+
+**3. Apply signal-threshold noise reduction**
+
+Before interrupting the user, evaluate signal strength:
+
+- **Weak signal** → auto-suppress: minority <5% AND count <10 → majority wins, minority goes to DONTs
+- **Strong signal** → grill: near-even split, or semantic fork on a core dimension
+- **Small-project exception**: sources ≲50, "3 vs 2" is NOT a majority → grill it
+
+**4. Resolve conflicts one at a time (Grilling Protocol)**
+
+For each strong-signal conflict, present exactly ONE question with 4 options:
+
+> Evidence: `pathA` uses style X, `pathB` uses style Y
+> WARNING: Risk: mixing both fractures the project style
+> Choose: `1` follow X  `2` follow Y  `3` this is evolution, update rules  `4` I have a new rule
+
+Suspend until the user answers, then proceed to the next conflict. Never stack questions.
+
+**5. Generate `.ai-style-rules.md`** with three mandatory sections:
+- **[Golden Files]** — real exemplar paths annotated with what they demonstrate
+- **[Naming & State-Control Rules]** — concrete, checkable conventions
+- **[DONTs]** — anti-patterns that must not propagate
+
+**6. Install the persistent hook**
+
+Ask the user for enforcement strength (use `AskUserQuestion`):
+
+| Option | Mechanism |
+|---|---|
+| **1** Soft hook (recommended) | Write `@.ai-style-rules.md` reference into project `CLAUDE.md` |
+| **2** Hard hook | Soft hook + `PreToolUse[Write\|Edit\|MultiEdit]` Hook in `settings.json` |
+| **3** No hook | Keep the rules file; user references manually |
+
+### Branch B — Incremental Sniff
+
+1. Read existing `.ai-style-rules.md`; if it has a commit fingerprint, `git diff <last_hash> HEAD --stat` to pinpoint delta
+2. Read recent Git changes (`git log -3 --stat` → inspect suspect files on demand)
+3. For oversized diffs (>hundreds of files): `--stat` summary only + sample the largest changes
+4. Compare new code against recorded rules → conflicts go through Grilling Protocol
+5. Append evolution log at the end of `.ai-style-rules.md` (never overwrite old rules)
+
+### Per-Turn Enforcement
+
+When `.ai-style-rules.md` is in context (loaded via CLAUDE.md), every code-writing task must open with a **compliance declaration** in the reasoning chain, naming the exemplar being followed and the DONTs being avoided.
+
+## How It Works
+
+This skill auto-detects whether it's a first-time or incremental run via `.ai-style-rules.md` presence:
+
+- **First-time (Branch A)** — Measures project scale, scans codebase across 4 meta-architecture dimensions (File Anatomy, State & Control Flow, Infrastructure, Error Handling), applies signal-threshold noise reduction to suppress weak conflicts, resolves strong-signal conflicts one-at-a-time with the user, generates `.ai-style-rules.md` with Golden Files / Naming Rules / DONTs, and offers optional enforcement hooks.
+- **Incremental (Branch B)** — Reads existing rules, checks recent Git diffs for new or conflicting patterns, runs the same one-at-a-time grilling protocol for any conflicts found, and appends evolution logs without overwriting existing rules.
+- **Per-Turn Enforcement** — When hooked via `CLAUDE.md`, every code-writing task opens with a compliance declaration naming the exemplar followed and the DONTs avoided.
+
+## Output Specification
+
+- `.ai-style-rules.md` at project root (with commit fingerprint + scale tier in header)
+- Optionally `CLAUDE.md` with `@.ai-style-rules.md` reference
+- Evolution logs appended as `### [YYYY-MM-DD] Style Evolution Log` entries
+
+## Anti-Patterns
+
+- FAIL: Do NOT skip the scale measurement step — sampling a 30-file project "starves" it; full-scanning a 5,000-file repo blows up
+- FAIL: Do NOT stack multiple conflict questions at once — grilling is strictly one-at-a-time
+- FAIL: Do NOT overwrite old rules in incremental mode — always append evolution logs
+- FAIL: Do NOT default to "hard hook" without asking — enforcement strength is the user's call
+- FAIL: Do NOT judge syntax or tech-stack quality — this skill aligns meta-architecture only
+- FAIL: Do NOT copy bugs from exemplar files — reuse structure, flag defects
+
+## Best Practices
+
+- Announce the detected mode (first-time vs incremental) and scale tier in one line before scanning
+- For large projects, read `--stat` summaries first, then targeted `Read` on suspect files
+- Let the signal threshold handle noise — a 843-vs-8 naming split should auto-resolve without user interruption
+- When in doubt about signal strength, lean toward asking
+- The CLAUDE.md soft hook (`@.ai-style-rules.md`) is usually sufficient; hard hook only if the user wants mechanical enforcement
+
+## Related Skills
+
+- `init` — initialize a new CLAUDE.md with codebase documentation
+- `code-review` — review diffs for correctness and style issues
+- `simplify` — review code for reuse and simplification opportunities
+
+## Examples
+
+1. **First-time onboarding**
+   - User: "Help me onboard AI to this older codebase without changing its style."
+   - Action: Run Branch A full-scan → measure scale → scan 4 dimensions → grill conflicts → generate `.ai-style-rules.md` → offer hook strength (soft/hard/none).
+
+2. **Incremental update after team changes**
+   - User: "We added a new module; keep existing style rules intact."
+   - Action: Run Branch B incremental sniff → compare Git deltas to recorded rules → grill any new conflicts → append evolution log without overwriting.
+
+3. **Enforcing DONTs via CLAUDE.md**
+   - User: "Make sure all new code stays consistent with the project's rules."
+   - Action: Soft hook installed → `.ai-style-rules.md` auto-loaded every session → every code-writing task opens with compliance declaration, reusing exemplar patterns and avoiding DONTs.