propose-adrlisted

<!-- このファイルは dev-templates 自身が dogfooding する mirror copy。 master は `templates/skills/propose-adr/SKILL.md`。 編集は templates/ 側で行い、`bash scripts/apply.sh` で同期する。 pre-commit hook (.githooks/pre-commit) が両者一致を検査し、drift を commit reject する (ADR-0008 fool-proof 多層防御)。 --> # Skill: Propose ADR Draft architecture-impacting な変更要求が検出された場合、Claude は **実装を着手 せず**、`docs/adr/drafts/proposed-<slug>.md` を ADR template ベースで 起票してユーザ review を待つ。本 skill は ADR-0023 の workflow D を 実装する。 ## When to invoke 以下 3 trigger のいずれかが検出されたとき: ### 1. `rule-violation` `source/rules/**/*.md` の `hard_constraints` / `must` 項目に違反する 実装要求を受け取った場合。 - 検出方法: rule frontmatter を parse → 実装内容と semantic 照合 - 確実性: 中 (false positive あり、ユーザ判断で吸収) - 例: `source/rules/common/file-granularity.md` の「1 file 500 行以下」を 超える生成要求 ### 2. `new-dependency` 依存関係 manifest の差分検出: - `build.gradle` / `build.gradle.kts` (Android / JVM) - `package.json` (Node.js) - `requirements.txt` / `pyproject.toml` (Python) - `Cargo.toml` (Rust) - `go.mod` (Go) - 検出方法: grep / diff (mechanical、高確実性) - false positive: 低 (manifest 差分は明示的な意思決定) ### 3. `architecture-drift` `docs/architecture.md` や既存 ADR に記載のないパターン採用: - 検出方法: 既存 ADR を context として LLM judge - 確実性: 低〜中 (semantic 判定、false positive 多め) - 例: 既存 ADR で禁じられたパターン、新規ストレージ層導入、外部 API 連携 ## Process 1. **実装着手前** に trigger を検出 2. `docs/adr/_template.md` をベースに `docs/adr/drafts/proposed-<slug>.md` を生成 - slug: 変更内容を表す kebab-case identifier - frontmatter: `adr: TBD`, `status: Proposed`, `propo