neckbeard

neckbeard

ソフトウェア開発のための、規律ある運用モデルです。キャラクターを演じるものではありません。エージェントが、変更の範囲を定め、設計前に実際のシステムを把握し、最小限の 安全な 介入を選び、段階ごとに実行し、証拠を記録し、証拠が尽きたら停止またはエスカレーションするという6つのことを、確実に行えるようにします。

この名前は、「Markdownファイルに書かれた10倍の開発者」という定番ネタをもじったものです。その中身は、そのネタとは正反対です。ここでの有効性は、ペルソナを掲げることではなく、観察可能な成果と範囲を限定した主張によって証明されます。

読み込むタイミング

バグの診断、機能の開発、リファクタリング、レビュー、リリースの検証など、単純ではないソフトウェア変更の依頼で、範囲を限定し、各段階を意識しながら、正当性を説明できる「完了」まで進める方法が必要なときにneckbeardを読み込みます。

使用しないタイミング

次の場合は読み込まないでください。

• 事実を尋ねる質問や情報の検索が1件だけの場合（そのまま回答してください）。
• 仕様がすでに完全に定まっている1行の編集の場合（そのまま実施し、境界では検証してください）。
• より専門的なスキルがすでに最初から最後まで担当しているタスクの場合（そちらに振り分けてください。references/routing-table.mdを参照）。

コアループ

すべての実行は、同じ流れに沿って進みます。各ステージの開始条件、 必要な証拠、終了条件、エスカレーションルールについては、 references/stages.mdで詳しく説明しています。

1. 変更の契約を明確にします。 ユーザーから見える問題、制約、 システム境界、リスク、明示的な対象外事項を記述します。調査する 権限と、変更、公開、デプロイ、マージする権限を区別します。 変更の正当性がない場合は早期に停止し、その判断の根拠を残します。 テンプレート：templates/change-contract.md。

2. 設計の前に調査します。 修正を提案する前に、実際のリポジトリ、 貢献ガイドライン、アーキテクチャ、呼び出し元、テスト、設定、最近の 変更を確認します。もっともらしいアーキテクチャの説明より、一次資料 （コード、テスト、実行時の出力、プロジェクトのドキュメント）を優先 します。未検証の仮定やアクセスできない情報は明示します。

3. 安全な介入のうち、最小のものを選択します。 まず既存のコードと プラットフォームの機能を再利用し、そのうえで検証済みの契約を満たす 最小限の実装を選びます。「差分を最小にする」ことは、理解の結果で あり、最適化の目標ではありません。信頼境界の検証、データの安全性、 セキュリティ、アクセシビリティ、可観測性、運用上の復旧、明示的に 要求された動作を犠牲にしてはなりません。意図的に設けた上限と、その 引き上げ条件を記録します。

   本番の動作がすでに正しく、カバレッジの不足や指定されたミューテー ションに対する集中的なガードを追加する場合は、テスト強化の依頼で あることを明示的に分類します。これは通常の本番バグ修正ではなく、 軽量パスのサブタイプです。新しいテストがクリーンなmainで失敗する ことを求める代わりに、ベースラインで成功し、ミュータントで失敗する 証拠を使用します。範囲を限定した契約とエスカレーション条件について は、references/lightweight-test-hardening.mdを読み込みます。

4. SDLCのステージに沿って実行します。 作業を担当するステージ （調査／要件定義、設計、実装、検証、デリバリー、学習）に割り当てます。 該当する専門スキルがある場合は、方法を独自に再構築せず、そのスキルを 読み込みます（ルーティング表を参照）。

5. 証拠台帳を維持します。 重要な実行ごとに、意図、確認した成果物、 仮定、却下した代替案、変更したファイル、実行したコマンド／チェック、 観測された出力、未検証の境界、ロールバック／フォローアップの条件を コンパクトに記録します。コンポーネントのチェックと、エンドツー エンドまたは本番境界のチェックを区別します。形式とルール： references/evidence-ledger.md。 テンプレート：templates/evidence-ledger.md。

6. ルールに従って停止し、エスカレーションします。 タスクに検証済みの 必要性がない場合、リスク／権限の境界で人間の判断が必要な場合、または 実質的に異なる2つのアプローチが失敗した場合は、停止して報告します。 粘り強さを理由に、権限の昇格、破壊的な復旧、際限のない回避策の繰り返し を行ってはなりません。ルール： references/risk-authority-gates.md。

非同期作業やステージ完了の判断には、 references/progress-and-finality.mdを使用します。 経過時間や観測の繰り返しではなく、意味のある進捗と明示された依存関係に 基づいて判断します。

変更依頼の作業（条件付き）

依頼が変更依頼、つまりプルリクエストまたは同等のレビュー可能な成果物につながるイシュー、チケット、追跡対象の依頼である場合、上記の6ステップのコアループが各段階を引き続き規定しますが、作業全体では標準の9フェーズからなる変更依頼のプロセスにも従います。

→ references/journey.md — 受付 → 調査 → 設計 → 仕様 → テスト計画 → 実装 → レビュー → リリース準備 → 承認済みリリース。

このプロセスでは、ゲート、フェーズをまたいで状態を引き継ぐためのデリバリーパケット、プラットフォームのライフサイクル上の仕組み（GitHub またはエンタープライズ）が追加されます。コアループに取って代わるものでも、第2のオーケストレーターを作るものでもありません。

次の場合はプロセスを読み込まないでください： イシュー／チケットの経過を伴わない単純な修正、リファクタリング、レビュー。この作業では、プロセスのフェーズ、パケット、ゲートを使わず、コアループと以下の各段階のリファレンスを使用します。

作業途中からの参加（条件付き）

別の場所で始まったデリバリー作業を引き継ぐ場合（実装途中のブランチ、採用済みの仕様、別のコントリビューターが着手した変更依頼など）で、デリバリーパケットが存在しないときは、フェーズ1からやり直したり、作業内容に関する説明文の要約をそのまま信頼したりしないでください。まず位置評価を実施します。確認可能な成果物を洗い出し、フェーズの終了条件に照らして評価し、位置レポート（現在のステップ、根拠への参照を含む充足済みゲート、残りのチェックリスト）を出力します。その後、パケットを初期化し、通常のプロセスに沿って続行します。

手順：references/position-assessment.md。これを読み込むのは作業途中から参加する場合のみです。新規の変更依頼はフェーズ1から開始し、既存のパケットがある場合は references/delivery-packet.md に従って再開可能性を判断します。

形式的な手順に入る前の作業パスの選択

現状の調査が終わった直後、パス固有の成果物を作成する前に、デリバリーパスを選択します。行数だけで判断せず、影響を受ける範囲とリスクを考慮してください。

テスト強化の依頼で軽量パスを選択できるのは、本番の動作がすでに正しく、本番コードに変更がなく、変更がテストまたはフィクスチャに限定され、焦点を絞った決定論的なチェックと、範囲を限定した制御可能な弱体化によってリグレッションを検出できる場合のみです。不変条件、クリーンなベースラインの根拠、名前を付けたミューテーション、対象外事項を記録してください。通常のバグ修正に求められる「新しいテストがクリーンな main で失敗すること」という要件は適用しないでください。

CI の実行コストが高い場合や実行が直列化されている場合は、最初のプッシュ前に、ローカル設計、ハーメチック性、焦点を絞ったテスト、対象を絞ったミューテーション、リント、コンパイル、スコープの各チェックに合格する必要があります。範囲を限定した最終レビューを1回、またはリポジトリで必須のプラットフォームレビューを1回依頼する前に、候補を凍結してください。タイムアウトしたレビューは結論が出ていない状態であり、レビューを繰り返す理由にはなりません。重要な変更を加えた場合は、該当する検証が無効になり、差し替え後の判定は新しい正確なヘッドにひも付ける必要があります。

テスト強化の詳細な契約とエスカレーションの条件は references/lightweight-test-hardening.md を参照してください。

「完了」を定義する唯一のルール

宣言した検証対象を実際に検証していない限り、「完了」としてはなりません。検証していない場合は、完了を主張するのではなく、未検証の部分を正直に報告してください。

ユニットテストに合格することと、デリバリー境界を検証することは同じではありません。ローカルでレンダリングすることは本番環境での検証ではありません。どの境界を確認し、どの境界を確認していないかを明示してください。 検証方法：カタログスキル verification-methodology を読み込みます。

正しくミニマリズムを取り入れる

このバンドルにおけるミニマリズムは、実際のフローを理解した後に選択する条件付きの設計方針であり、「行数が少ないほどよい」という無条件の反射ではありません。より大きな変更、新しい依存関係、プロセスの変更、あるいはコードを一切変更しないことが正解の場合もあります。評価用フィクスチャには、反射的な削除や圧縮ではバンドルが高い評価を得られないよう、意図的に敵対的なケースが含まれています。references/stages.md §3 を参照してください。

ルーティング：取り込んで、抱え込まない

neckbeard が担うのは、変更コントラクト、エビデンス台帳、停止ルール、評価プロトコルといったステージ間のコントラクトです。ドメイン手法は担いません。あるステージに専門スキルがある場合は、それを読み込んで従ってください。「既存のスキルを代わりに使う」条件を含む完全な表は references/routing-table.mdを参照してください。概要：

ステージ／ニーズ	独自に方法を考える代わりに読み込むカタログスキル
ステークホルダーの発見、要件、AC	product-discovery
ユーザー向けの動作、インタラクション、情報アーキテクチャ	product-design-and-ux
正式な仕様、フェーズゲート	spec-driven-development
既存のコードベースのリバースエンジニアリング	software-architecture-analysis
API／インターフェースコントラクトの設計または進化	api-design-and-evolution
根本原因のデバッグ	systematic-debugging
セキュリティレビュー、脅威モデリング、安全な設計	secure-software-engineering
アクセシビリティ（WCAG、キーボード／フォーカス、エラーからの復旧）	web-accessibility
テスト戦略、回帰テスト、CI 品質ゲート	qa-methodology
モバイルアプリの実装（iOS／Android／Flutter／React Native）	mobile-development
ドキュメント／README／API リファレンス	technical-documentation
検証結果の判定とエビデンス	verification-methodology
実行全体にわたる意図のコントラクト、作業の分類、自律性のゲーティング、障害のルーティング	bmad
リリース計画、バージョン管理、パイプラインの昇格、準備状況、ロールアウト、ロールバックの設計	release-engineering
信頼性、インシデント対応、運用上の復旧	site-reliability-engineering

専門スキルがインストールされていない場合、neckbeard のステージリファレンスが最小限の代替手法を提供します。ただし、台帳には専門スキルがなかったことを記録してください。

評価も第一級の成果物です

このバンドルには、バージョン管理された評価ハーネスがeval/に含まれています。バンドルが改善をうたう SDLC の成果、つまり正確性、回帰への安全性、スコープの規律、境界の検証、誠実な不確実性を測定します。コード行数や応答の簡潔さは測定しません。改善を主張する前に、公開スイートを実行し、メンテナーのワークフローを通じてホールドアウト結果を報告してください。方法論： references/evaluation.md。

主張に関するポリシー。 パフォーマンスに関する主張はすべて、評価対象のモデル、ハーネス、リポジトリ、タスククラス、日付の範囲内に限定してください。公開され、再現可能な定義とエビデンスがない限り、「開発者の生産性を10倍にする」「常に」「最高」など、全般的なパフォーマンスを主張する表現は使わないでください。コード行数は診断用メタデータとしてのみ記載でき、成功の代理指標として使ってはいけません。

ファイル一覧

パス	読み込むタイミング
references/stages.md	SDLC の各ステージに入るとき。各ステージの開始条件／エビデンス／終了条件／エスカレーションを定義します
references/evidence-ledger.md	台帳の作成または監査時。必須フィールドと境界ルールを定義します
references/risk-authority-gates.md	変更、デプロイ、マージ、または破壊的な操作の前、および停止／エスカレーション時
references/routing-table.md	現在のステージを専門スキルが担当するかどうかを判断するとき
references/journey.md	変更リクエスト作業のみ — PR または同等のレビュー可能な成果物につながる課題／チケット／リクエスト。9 フェーズの受付→リリースの手順、ゲート、経路を定義します。課題／チケットに基づく進行のない単純な修正、リファクタリング、レビューでは読み込みません（その作業では上記のコアループを使用します）。
references/lightweight-test-hardening.md	すでに正しい本番環境の動作に対する、テストのみの回帰防止策：ベースライン合格／ミュータント失敗のエビデンス、密閉性、プッシュ前の最終確認、範囲を限定したレビュー、エスカレーションのトリガー。
references/lifecycle.md	変更リクエスト作業のみ — 受付、提出、CI／レビューの監視、承認済みリリースのためのプラットフォーム上の仕組み（GitHub 参照モードまたはエンタープライズモード）。課題／チケットに基づく進行のない単純な修正、リファクタリング、レビューでは読み込みません。
references/delivery-packet.md	変更リクエスト作業のみ — 変更リクエストの実行中にフェーズ間で状態を引き継ぐ場合、またはコンテキスト境界を越えて再開する場合。パケットのフィールド、成果物の所有権、ライフサイクルの状態、再開可能性を定義します。課題／チケットに基づく進行のない単純な修正、リファクタリング、レビューでは読み込みません。
references/position-assessment.md	進行中の作業への参加のみ — 別の場所で開始され、デリバリーパケットがないデリバリー作業を継続する場合：成果物の一覧作成、終了条件の評価、位置レポート、パケットの初期化。
references/tracker-discovery.md	変更リクエストの受付 — 作業項目を管理するトラッキングシステムを特定し、トラッカーの操作を対応するカタログツールスキルに振り分けます。ジャーニーの用語は特定のトラッカーに依存しません。
references/evaluation.md	評価の設計、実施、または報告時
templates/	変更契約、意思決定記録、エビデンス台帳、検証計画、評価レポート、および templates/delivery-packet.md — 記入式パケット。変更リクエスト作業のみ（課題に基づく進行のない単純な修正／リファクタリング／レビューには使用しません）
eval/	タスクスキーマ、評価基準、ベースラインプロトコル、フィクスチャ、ランナー