ヘビーなCLIなしのSpec Kit：Cursorで仕様駆動開発をプロジェクトに適応させる

この記事は、Cursorでspec駆動型AI開発を利用したいと考えているが、GitHubから完全なSpec Kitを展開することなく利用したい開発者、アナリスト、テクニカルライターを対象としています。完全なパイプライン（constitution、specify、plan、tasks、implement）の代わりに、彼らは最小限のセットを提案しています：不変のリポジトリルールを持つconstitution、タスクの仕様、明示的な人間の合意（エージェントは自己合意できない）、合意された仕様に基づく実装、そして進行中の作業へのポインタ。彼らは、plan、tasks、一括リビルドのような追加のステップはしばしば冗長であり、ノイズを生み出し、上書きのリスクがあると主張しています。適応されたアプローチは3つの部分から構成されています：Cursorルール（常にコンテキスト内）、スキル（/project-init、/project-specify、/project-implementなどの明示的なコマンド）、リポジトリ成果物（constitution、specs、drafts、feature.jsonポインタ）。ワークフローは、init、specify、人間の合意、implementです。constitutionは、プロジェクトの目標、パイプラインの段階、避けるべきこと（plan/tasks）、セマンティックレイヤーと結果レイヤーの分離、[NOT KNOWN]タグによるソースへの忠実性、実装のためのreasoning_temperatureを低く設定すること、秘密情報の禁止、constitutionを変更するための明確な手順を義務付けています。実装は、仕様が合意されたステータスを持ち、ブロックする未知の項目がない場合にのみ許可されます。また、一般的な誤りについて概説し、簡素化されたサイクルは増分タスクに十分である一方、完全なSpec KitはそのCLIや標準的なマルチステップパイプラインを必要とする人向けであると述べています。両方のアプローチは互換性があり、成果物は再利用できます。記事は、ディレクトリ構造よりもパイプラインの規律を強調して締めくくっています。