adr
Write an Architecture Decision Record (ADR) for a feature — Context / Decision / Status / Consequences / Alternatives, filed as…
Install plugin rules into project .claude/rules/ for persistent use without plugin loaded
$ npx -y skills add sd0xdev/sd0x-dev-flow --skill install-rules --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/install-rulesContext preview
The summary Claude sees to decide when to auto-load this skill.
Install plugin rules into project .claude/rules/ for persistent use without plugin loaded
name: install-rules description: "Install plugin rules into project .claude/rules/ for persistent use without plugin loaded" allowed-tools: Read, Grep, Glob, Write, AskUserQuestion, Bash(mkdir:*), Bash(diff:*), Bash(git:*), Bash(ls:*)
Phase 1: Locate plugin rules dir Phase 2: Enumerate *.md, MINUS the override templates (*-project.md) — see below Phase 3: Determine install set (--all, specific names, or interactive) Phase 3.5: Read manifest + classify (new/unchanged/modified/conflict) Phase 4: Install (smart merge with manifest tracking) Phase 4.5: Override templates — copy-when-absent only (never smart-merged) Phase 4.6: Backfill CLAUDE.md references Phase 5: Output report
**Managed-set exclusion (required)**: `*-project.md` files are user-owned and must be excluded from the Phase 2 enumeration, so they never enter the manifest, the classification in Phase 3.5, or the smart merge in Phase 4. They are handled only by Phase 4.5 below. Routing them through the managed path would let `--force`, a conflict resolution, or an auto-upgrade rewrite a file the user owns.
$ARGUMENTS
| Argument | Description | |----------|-------------| | `--all` | Install all available rules | | `--list` | List available rules without installing | | `--dry-run` | Show what would be installed, no changes | | `--force` | Overwrite modified rules | | `--legacy-strategy <strategy>` | Handle pre-manifest installs (ask/overwrite/skip) | | `--customize <rule>` | Customize a project-override rule | | `rule-names...` | Specific rules to install |
Uses `.sd0x/install-state.json` to track installed file hashes. Smart merge logic:
| Status | Action | |--------|--------| | New (not installed) | Copy | | Unchanged (hash match) | Auto-upgrade | | Modified by user | Skip (preserve edits) | | Conflict (both changed) | AskUserQuestion |
Manages `*-project.md` companion files for user overrides:
| Sub-flag | Action | |----------|--------| | (none) | Show section status | | `--add-section` | Add a new section | | `--update-section <name>` | Update specific section | | `--reset` | Regenerate from template |
Both override templates are copied from `rules/` on install when absent (`override_templates` in `docs/features/rule-override-pattern/2-tech-spec.md` maps `auto-loop.md → auto-loop-project.md` and `testing.md → testing-project.md`). This is the **only install or re-install path** that writes them — they are excluded from the managed set above, so no merge, upgrade, or `--force` reaches them. (The one other writer is the user-invoked `--reset`, below.)
The copy and `--reset` regeneration produce the **live-precedence header** (a live `Precedence:` paragraph before the first `##` — HTML comments are stripped from model context, so a comment-form declaration never reaches the model), and stamp `<!-- Based on: <base> @ <hash> -->` with the base rule's blob hash **at copy time** rather than carrying the template's recorded value, so a fresh install starts at zero drift instead of inheriting whatever hash the shipped template happened to record.
An already-installed `.claude/rules/*-project.md` is user-owned and is **never rewritten by install or re-install** — including `--force`, which governs the managed set only. The single exception is `--customize <rule> --reset`, which the user invokes explicitly against a named file to regenerate it; that is a requested overwrite, not an install-time one. A legacy comment-only header is therefore *reported* by `/claude-health` S2.5 check #6 and never migrated on the user's behalf — `--reset` is offered as the remedy the user may choose, not an action the install path takes.
## Install Rules Report | Rule | Status | Action | |------|--------|--------| | auto-loop.md | unchanged | auto-upgraded | | testing.md | user-modified | skipped | Installed: N | Skipped: M | Conflicts: K
Language: English | 繁體中文 | 简体中文 | 日本語 | 한국어 | Español The harness layer for Claude Code. Let the model choose the path. Keep "done" verifiable. Full control plane on Claude Code. Skills-only distribution for Codex CLI and other compatible agents.
Repo: sd0xdev/sd0x-dev-flow
Write an Architecture Decision Record (ADR) for a feature — Context / Decision / Status / Consequences / Alternatives, filed as…
Architecture design and documentation. Produces 3-architecture.md with component diagrams, data flow, integration points, and architecture decisions. Reads…
Context-aware Q&A with auto context gathering. Use when: user has a quick question about codebase, git history, rules, docs, or skills during development. Not…
Industry best practices conformance audit with mandatory adversarial debate. Produces audit artifact: verdict (OK/WARN/FAIL) + gap roadmap + debate proof. Use…
Bug fix workflow. Use when: fixing bugs, resolving issues, regression fixes. Not for: new features (use feature-dev), understanding code (use code-explore).…
Bump package and plugin version in sync. Updates package.json, .claude-plugin/plugin.json, and install-state manifest to the same version. Use when: user says…