Communityライティング&編集github.com

dev-discipline

バグ修正、リグレッション、失敗するテスト、またはコードの正しさを判断するあらゆる変更(テスト、バリデーター、しきい値、CI、金銭・数式、マイグレーション、認証など)を行う際に使用します。

dev-discipline とは?

このスキルは、開発プロセスに厳格な規律を課すための包括的なフレームワークです。テスト、バリデーター、しきい値、CIなど、コードの正しさを判断するあらゆる要素の変更から、金銭や数式、マイグレーション、認証に至るまで、あらゆる重要な変更に対して「証明可能な修正」を要求します。具体的には、変更前の測定、根本原因の修正、アサーションによるテストの証明、ゲート(CIでの自動チェック)の追加、そして変更者自身が調整していない外部オラクルによる検証という6段階のループに従います。このスキルは、たとえばClaude CodeのようなAIエージェントで使用され、開発者が「Done(完了)」を自己判断するのではなく、外部シグナルによって証明されるように設計されています。スキルが提供するスクリプト群(`scripts/prove_fix.py`、`scripts/guard_diff.py`など)を活用し、すべての変更に証拠を残し、スキップやテストの弱体化を禁止することで、ソフトウェアの品質を機械的に保証します。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/volniy082-spec/dev-discipline/tree/HEAD

Installed? Explore more ライティング&編集 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

Dev-discipline(開発規律)

「完了」とは、あなたが調整していない外部シグナルによって示されるものです。 書かれたルールは失敗のクラスに名前を付けるだけであり、ゲート内のチェックがそれを阻止します。あるクラスが再発した場合、同じコミット内でチェックを追加してください。 $DD = このファイルの隣にある scripts/ フォルダ(exit 0 で PASS、1 で FAIL、2 で NOT_PROVEN)。

表面ごとの厳密さ。 判断を行うもの(テスト、バリデーター、しきい値、CI)、金銭・数式、マイグレーション、認証、サイレント障害に対してはフルループを実行します。仕様リテラルを含む約10行のローカル修正の場合:prove_fix.py、欠陥クラスの手書きミュータント2~3個、作業中に使用しなかった入力を用いた1回の実行。散文、UIの見た目、ドキュメント、プロトタイプ:テストと1回のスモークテストを実行します。テストやランナーが存在しない場合:独自のコミットで最小限のものを追加します(セットアップであり、弱体化ではありません)。

ループ

  1. 編集前に測定する: 変更前後で比較する1つのコマンド。スコープは生データから導出し、要約や記憶からは導出しません。クラス全体をリストアップします:同じルートを共有するすべてのインスタンス。 → references/debugging.md
  2. 欠陥がたどった経路上の根本を修正する。 上部へのガードは修正ではありません。リグレッションの場合:git bisect run。3回試行が失敗した後は、アプローチまたはコンテキストを変更します。新しいエンティティ、金銭・データフロー、またはマイグレーションの場合:最初に5~10行の設計ノートを作成します(debugging.md §10)。
  3. テストを証明する: 親に対してアサーションによって赤(ImportError、収集エラー、スキップはNOT_PROVEN)、修正後に緑、コード変更を元に戻して再び赤:$DD/prove_fix.py。新しいチェックは悪い入力で発火し、良い入力では静かに保たれます。金銭と数値の場合、期待値は仕様リテラルです(# oracle: <source>)。
  4. ゲート: 同じコミットでテストがCIで実行されます。スキップ、タイムアウト、「0 tests」はPASSではありません。除外リストは縮小のみ可能です。グロブやレジストリに対するループは、見つかった項目数をアサートします。 → gate-integrity.md
  5. 受け入れる: パイプラインの $? ではなく、最終実行のランナーのサマリー行で、正確なツリー上での実行結果を受け入れます。
  6. 閉じる: 書き手が調整していないチェック(他のデータ、読み取り専用のプロダクションスモーク、独立したオラクル)と、事前に書き留めた期待値で閉じます。それによって見つかったクラスはゲートに入れます。 → proof-and-oracles.md

オラクルとその保護

  • オラクルはチェック対象のコードとコードを共有しません。ゴールデンや自己パリティは一貫性を証明しますが、正しさは証明しません。
  • 検証スクリプトはテスト対象のコードです:良い入力と悪い入力で実行し、検査した項目数を表示します。
  • テスト、スナップショット、期待値、CIは契約によってのみ変更されます:ブリーフ、または単独作業の場合は変更内容を指定するユーザーリクエスト(新しい仕様、チケット、値)と、編集前に書かれた1行(どのテストが変更されるか、新しい値がどこから来るか)。「パスさせる」は契約ではありません:仕様と矛盾するテストはそのまま残され、答えはSPEC_CONFLICTとなります。値の変更は別のtest:コミットに入れます。スキップ、削除されたアサーション、縮小されたカバレッジには理由の記載が必要です。 期待値に合わせるためにコードを調整してはいけません。最終的な差分を判断し、編集ツールは判断しません:$DD/guard_diff.py(最初は助言)。正当な作業をブロックするチェックは欠陥です:BLOCKEDを報告し決してバイパスしてはいけません。 → oracle-protection.md

自律性

デフォルトで進行します。不可逆的なこと(セキュリティ、支払い、プロダクションデータへの書き込み、権限)または目標との衝突についてのみ質問します。分岐点では、1つを選び、その理由、両方の読み取り値の数値、元に戻す方法を記録して続行します。ブロックされた場合:独立したすべてを完了させ、最後に必要なアクションとコマンドを1行で示して終了します。

報告

  • 各基準は PASS | FAIL | NOT_PROVEN とコマンド、終了コード、出力行を記載します。さらに not_checked も含めます。
  • 評決:DONE、BLOCKED(reason)、SPEC_CONFLICT(test, source)、IMPOSSIBLE、NOT_REPRODUCED。完了しなかった旨の正直な終了は成功です。黙ったスキップは欠陥です。部分的な状態に名前を付けます(「ガード追加、ルート生存中」)。
  • すべての数値は、最終実行のコマンドとともに記載します。サブエージェントが報告した数値は再実行します($DD/reexec_claims.py)。
  • コミット本文 = 証拠記録:変更前後の測定、ゲート行、完了していないこととその場所。

レッドフラグ

気づいたこと実行すること
親に対して赤がない状態で緑prove_fix.py
サブエージェントの数値や自分の記憶を引用している再実行する
契約なしでテストやしきい値を編集している契約行または SPEC_CONFLICT
緑を得るためにskip, retry, sleep, noqaを使用している原因を見つけ、決定論的にする(refactor-flaky.md)
可逆的なことについて質問しようとしている決定し、記録し、続行する

詳細:delegation.md(サブエージェント、レビュアー、ブリーフ)、release.md(デプロイ)、process-ledger.md、evidence.md。

関連スキル