go

目次

• 使用する場面
• 必須入力
• 成果物
• スタイル
• エラーフロー
• 例
• 失敗モード
• 注意点

使用する場面

• Go コードの作成およびレビュータスクに使用します。
• パッケージの境界とエラーハンドリングを厳密にする必要がある場合に使用します。

必須入力

• パッケージとファイルのスコープ。
• 期待される API の動作。
• ランタイムおよびパフォーマンスの制約。

成果物

• Go らしい変更。
• ラップされた実行可能なエラー。
• リクエストされたスコープ外での最小限の API 変更。

スタイル

• 関数は小さく、パッケージフォーカスで保つ。
• インターフェースが不要な場合は、コンストラクタから具体的なストラクトを返す。
• 深いエンベディングチェーンよりもコンポジションを優先する。

エラーフロー

• %w でラップされたエラーを返すことでトレーサビリティを確保する。
• ライブラリコードでの panic を避ける。
• 返されたすべてのエラーをチェックして処理する。

例

func ParsePort(value string) (int, error) {
	port, err := strconv.Atoi(value)
	if err != nil {
		return 0, fmt.Errorf("parse port %q: %w", value, err)
	}
	return port, nil
}

失敗モード

• API 互換性のリスクが高い場合は、署名を安定的に保ち、パッチを絞る。

注意点

• 無視されたエラーは通常、ランタイムバグになります。

関連項目

スキル	使用する場面
[[rust-pro]]	エラー伝播とオーナーシップの懸念が類似するシステムプログラミング
[[he-fix-bugs]]	証拠ファーストの診断による Go ランタイムエラーの分類

トピックマップ: [[agent-ops]]

哲学

• 最小限の必要な変更で、明確で検証可能な成果を最適化する。
• 繰り返し実行しても一貫した判断が得られるよう、ガイダンスを決定的に保つ。

手順

1. 編集前にスコープ、制約、および必須入力を確認する。
2. リクエストされた成果に直結するフォーカスされた変更を適用する。
3. 最もシグナルの高い検証を再実行し、具体的な証拠を取得する。

検証

• タッチされたファイルとワークフロー契約に関連するローカルチェックを実行する。
• 高速フェイル：最初のブロッキング検証エラーで停止し、正確な証拠をレポートする。
• 修正後に再度チェックを実行し、残っていればリスクを記録する。

制約

• デフォルトでシークレット、トークン、認証情報、および機密データを削除する。
• 明示的に要求されない限り、スコープを拡張しない。
• 広範なリファクタリングより、安全で可逆的な編集を優先する。

アンチパターン

• 変更後の検証をスキップする。
• 狭い問題を解決するために広範なリファクタリングを適用する。
• 現在のチェックからの証拠なしに動作を仮定する。

参考資料とアセット

• 詳細なガイダンス：Infrastructure/references/deep-guidance.md
• 読む場面：タスクが高度なエッジケース、マイグレーション対応パターン、またはコア チェックリストを超えたランタイム固有のニュアンスが必要な場合。