菜单
このリポジトリで、トレードオフを伴う設計判断や運用判断を Architecture Decision Record として docs/adr に作成・更新するときに使う。パッケージ責務、依存方向、セキュリティ境界、リリース方式、外部ツール連携、互換性方針、テスト戦略など、後から理由を参照したい判断に適用する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | adr-workflow |
| description | このリポジトリで、トレードオフを伴う設計判断や運用判断を Architecture Decision Record として docs/adr に作成・更新するときに使う。パッケージ責務、依存方向、セキュリティ境界、リリース方式、外部ツール連携、互換性方針、テスト戦略など、後から理由を参照したい判断に適用する。 |
トレードオフを伴う判断を docs/adr/ に記録する。
docs/plans/ は実装ログ、docs/design.md は現在の設計、ADR は判断の理由と代替案を残す文書として扱う。
次の条件を一つでも満たすなら ADR を作る。
docs/design.md に結論だけを書くと、理由や不採用案が失われる。通常のバグ修正、局所的なリファクタリング、単純な実装手順だけなら ADR は作らない。
その場合は docs/plans/ の実装ログで足りる。
docs/adr/README.md と docs/adr/template.md を読む。docs/design.md、docs/roadmap.md、直近の docs/plans/ を読む。docs/adr/ の最大連番を確認し、次の NNN-kebab-case-topic.md を作る。docs/adr/template.md を写し、今回の判断に不要なプレースホルダを削る。Status は採用前なら Proposed、採用する変更と同じ PR に入れるなら Accepted にする。Consequences には良い影響だけでなく、運用コスト、制約、将来の変更時の注意を書く。過去 ADR は判断の履歴として残す。
判断が変わる場合は、既存 ADR を大きく書き換えず、新しい ADR を作って Supersedes と Superseded by を相互に更新する。
軽微なリンク切れや誤字は既存 ADR を修正してよい。 判断の理由、代替案、影響を変える修正は新しい ADR にする。
ADR を作ったら、次を点検する。
docs/design.md: 採用済みの現在設計として反映する必要があるか。docs/roadmap.md: フェーズや完了項目として記録する必要があるか。docs/plans/: 実装ログから ADR へリンクする必要があるか。.agents/skills/: 今後のエージェント作業の手順を変える必要があるか。ADR は日本語で書く。 一文ごとに改行し、見出しは具体的な名詞句にする。 「重要」「包括的」「多角的」のような評価語だけで理由を済ませない。 トレードオフは、選択肢ごとに得るものと失うものを明示する。
文書だけの変更でも pnpm format を実行する。
skill を変更した場合は quick_validate.py で SKILL.md の frontmatter を検証する。
このリポジトリで機能・フェーズを実装する際の標準ワークフロー。プラン作成 → 仮説検証ループでの実装 → ドキュメント更新の3ステップを回す。新機能やロードマップの次フェーズに着手するとき、実装方針を整理したいときに使用する。
Repository-specific release workflow for llvm-analyzer. Use when adding or checking Changesets, preparing Version PRs, diagnosing GitHub Actions release jobs, publishing the VSCode Marketplace extension with OIDC, or changing release/version/changelog automation.