HN 日本語サマリー

← 一覧へ戻る
プログラミング

Claude CodeとCodexにチームのコーディング標準をもたらすエージェントスキル

Agent skills that bring team coding standards to Claude Code and Codex (github.com)

5 pointsby kanfilior0 コメント

要約

この記事は、エンジニアリングチームがAIエージェントを統合し、共有されたコーディング標準とチームの指示を強制するためのオープンソースプロジェクト、ADLC Team Skillsを紹介しています。バージョン管理されたチームのコンテキストモジュール、ルール、スキルのリポジトリを通じてAIエージェントを管理し、個々の「バイブコーディング」を超えて、混沌とした技術的負債やコンテキストの陳腐化を防ぐことを目指しています。このシステムは、AIエンジニアリングにおける信頼と検証のボトルネックを解消し、チーム全体の生産性とコード品質の向上を支援します。

全文翻訳

ADLCチームスキル — エンジニアリングチームのためのエージェント型SDLCサイロでのバイブコーディングを停止する。エンジニアリングチームのための共有認知レイヤーを構築する。個々のプロンプトハックは、ソロ開発者にとって迅速な成果を生み出しますが、チーム全体にスケールすると、「バイブコーディング」は混沌とした技術的負債、コンテキストの陳腐化、レビュー不能なPR、コード所有権の喪失につながります。スピードは解決されました。信頼と検証がAIエンジニアリングにおける新たなボトルネックです。ADLCチームスキル(tikalk/adlc-team-skills)は、12ファクターエージェント型SDLCのオープンソースチームレイヤーです。AIエージェントを孤立した推測者から、チームの憲法、製品戦略、アーキテクチャ標準、評価ベンチマークを共有する、準拠した説明責任のあるチームメンバーに変えます。チームAIディレクティブ(tikalk/agentic-sdlc-team-ai-directives)は、バージョン管理されたコンテキストモジュール(憲法、ルール、ペルソナ、例)、CDRインデックス、スキルマニフェストを保持するコンパニオンリポジトリです。クイックスタート# スキルをインストールし、スラッシュコマンドを生成し、session_startイベントを配線するnpx adlc-skills-cli add tikalk/adlc-team-skills -a opencode# またはnpx skillsのみ(コマンド/イベントなしのスキル)でnpx skills add tikalk/adlc-team-skills -a claude -gエージェントスキル標準をサポートする任意のAIエージェント — Claude Code、Codex、OpenCode、Cursor、GitHub Copilotなど — でそのまま動作します。スラッシュコマンド+イベント:adlc-skills-cliはnpx skills addをラップし、さらに9つのコーディングエージェントのために/nameスラッシュコマンドを生成し、session_startイベントフック(.events.json経由)を配線します。.events.jsonのないスキルリポジトリは、コマンドのみを取得します。ユニバーサルオーケストレーション:mission-briefは、任意のソース(mattpocock/skills、addy osmani/agent-skills、superpowers、spec-kit、または独自のソース)からスキルを自動検出し、ミッションパイプラインに動的に配線します。ベンダーロックインはありません。ゴールデンパス — 新しいteam-ai-directivesチームをブートストラップします。team-bootは、イベントフックを介してセッション開始時に自動実行されます。設定されていないプロジェクトでは、ユーザーに/team-setupの実行を促す警告が出力されます。team-setupはオンデマンドでも利用可能です:npx adlc-skills-cli add tikalk/adlc-team-skills -a opencode# スキル+コマンド+イベントをインストールしてから、モード3 — 新しい空のteam-ai-directivesをスキャフォールドするか、モード1 — GitHubからクローンするかを選択します。team-setup → 宛先(デフォルトは./team-ai-directives)+チーム名を選択 → README / AGENTS.md / CDR.md / .skills.json / 憲法のプレースホルダー / OKFインデックスファイルをスキャフォールド+ git initteam-constitution → 対話的にプレースホルダーを実際の原則に置き換えますteam-boot(自動)→ セッション開始時に憲法+CDRインデックス+PDR/ADRインデックス+スキルをシステムプロンプトに組み立てますすでにディレクティブリポジトリをお持ちですか?team-setupは他の3つのモードを提供します:モード1 — GitHubからクローン(例:tikalk/agentic-sdlc-team-ai-directivesをフォーク)モード2 — 既存のローカルパスを指定(すでに持っているリポジトリを配線)モード4 — すでに設定済み(既存の設定を確認)コードとしてのディレクティブ:4つのチームの柱[ グレートフィルター ](人間のチームリードのマクロレビュー)▲ │ ┌──────────────────┴──────────────────┐ │ 柱4:ガバナンスと評価 │ │(ティア1高速チェック+LLMジャッジ)│ └──────────────────▲──────────────────┘ │ ┌──────────────────┴──────────────────┐ │ 柱3:仕様駆動ワークフロー │ │(契約優先ミッションパイプライン)│ └──────────────────▲──────────────────┘ │ ┌──────────────────┴──────────────────┐ │ 柱2:製品とアーキテクチャ │ │(製品PDR+アーキテクチャADR)│ └──────────────────▲──────────────────┘ │ ┌───────────────────┴───────────────────┐ │ 柱1:戦略とチームディレクティブ│ │(team-boot / levelup / CDRリポジトリ)│ └───────────────────────────────────────┘ 🏛️ 柱1:戦略とチームディレクティブ(チーム優先アライメント)要因I — 開発者はオーケストレーター。要因X — コンテキストエンジニアリング。要因XI — コードとしてのディレクティブ。AI戦略の中心にチームを置きます。個々の開発者がローカルマシンでプロンプトショートカットを独占する代わりに、チーム標準はバージョン管理されたGitリポジトリ(team-ai-directives)に存在します。team-boot:イベントフックを介してセッション開始時に自動実行され、チーム憲法、CDRインデックス、PDR/ADRインデックス、スキルレジストリをシステムプロンプトに組み立てます。team-discover:チームコンテキストモジュールを再スキャンして、明示的な構造化された検出テーブルを取得します。/team-discoverから利用可能です。team-constitution:エンジニアリングチームのコア原則を対話的に定義、レビュー、または修正します。team-repair:CDR.mdを再インデックス化し、ルールの競合をスキャンし、ディレクティブの鮮度を確認します。team-boot → 憲法+CDRインデックス+PDR/ADR+スキルをシステムプロンプトに組み立てますteam-discover → 構造化された検出テーブルの С手動再スキャン(/team-discover)team-constitution → チーム憲法を対話的に作成または修正しますteam-repair → CDR.mdを再インデックス化し、競合をスキャンし、鮮度を確認します🎯 柱2:製品戦略とアーキテクチャガバナンス(PDRとADR)要因III — ミッション定義。要因IV — 構造化計画。要因IX — トレーサビリティ。文書化された決定がない場合、すべての実装セッションで製品の意図とアーキテクチャのルールが再導出(または誤解)されます。製品決定記録(product-*):製品決定を個々のPDRファイルとしてキャプチャし、対話的な明確化ワークフローを通じて曖昧さを解決し、自己完結型のPRD.mdにコンパイルします。アーキテクチャ決定記録(architect-*):Rozanski & Woodsの視点(機能、セキュリティ、デプロイメント、パフォーマンス)を使用してアーキテクチャ決定をリバースエンジニアリングまたは定義し、それらを統一されたAD.mdに構成します。product-roadmap:4つの真実のレイヤー(決定(PDR)、実行(MCP経由のライブ問題)、コード証拠、マイルストーンゲート)にわたるマイルストーンの進捗を追跡します。製品:product-init → product-clarify → product-implement → product-analyzeアーキテクチャ:architect-init → architect-clarify → architect-implement → architect-analyzeロードマップ:product-roadmap(PDR +問題+コード+ゲートを追跡)📐 柱3:仕様駆動ワークフロー(「コードではなく仕様をデバッグする」)要因III — ミッション定義。要因IV — 構造化計画。要因V — トリアージと実行。要因XIII — ループエンジニアリング。AIは強迫的な推測者です — 曖昧さに直面すると、質問する代わりに解決策を発明します。会話モデルから契約モデルに移行します。mission-brief:チームの自律パイプラインランナー。機能プロンプトを受け取り、正式な契約(目標、制約、非目標、成功基準)を導き出し、順序付けされたステップリストを生成し、完了までspecify → plan → tasks → implement ↺ convergeループを歩みます。マントラ:「コードではなく仕様をデバッグする」:エージェントが間違いを犯した場合、コードを修正するだけでなく、間違いが決して繰り返されないように仕様に欠落している制約を追加します。mission-brief "add user profile API with JWT" ├── Phase 2: Brief (Goal, Constraints, Non-Goals, Success Criteria) ├── Phase 3: Route Classification (spec | change | quick) ├── Phase 4: Discovery (auto-wires local installed skills & SDD frameworks) └── Phase 5: Execute (specify → plan → tasks → implement ↺ converge) 🛡️ 柱4:チームガバナンス、検証優先評価、「ビルドして削除する」要因VII — 検証優先評価。要因VIII — ラチェット効果。要因IX — トレーサビリティ。要因XII — ビルドして削除する。コードを書いたエージェントにコードが良いかどうかを決定させないでください。「メーカーとチェッカーを分離する」。evals skills:Eval駆動開発(EDD)を使用して、アプリケーションレベルの評価スイート(PromptFooまたはDeepEval)を構築します。人間のマクロレビューがグレートフィルターで行われる前に、定義されたビジネスリスクに対してコードをテストするために、ティア1の高速チェック+ティア2のLLMジャッジサブエージェントを実行します。levelup:セッションの勝利を永続的なチームメモリにキャプチャします。levelup-specifyはセッション実行トレースを抽出し、再利用可能なルール(コンテキストディレクティブレコード — CDR)としてGitにコミットします。「ビルドして削除する」:基盤となるモデルが改善されるにつれて、古いルールとプロンプトのスキャフォールディングをチームのrepair --build-to-deleteを使用して削除します。LevelUp:levelup-init → levelup-specify → levelup-clarify → level