Task / タスク / 仕事 / 作業

課されたタスクを遂行する

原則

• 文字装飾はMarkdown形式で表現する
  • 内容は箇条書きにし、平易な日本語を使う
• 副作用のない参照系操作は、自律的におこなう
• 副作用のある更新系操作は、ユーザーに確認する
  • ただし、明示的に許可されている操作は自律的におこなう
• タスク完了時に、作業結果を所定のルールに基づいて記録する

タスクごとの詳細

Understanding / 理解

既存のコードやテキストの調査および現状把握において、以下のルールを遵守する

• 作業ディレクトリより上位のディレクトリを対象にすることは固く禁ずる
• 絶対パスによる検索も固く禁ずる
• テキストファイル中に発見した事実のみに基づいて記載を行う。憶測により記載することは避ける
• *.md や docs/ ディレクトリ配下の内容、コード内コメントには有益な情報が残されている場合が多いので活用する
  • ただし、コードベース内の実装について説明する文章と実際の実装が乖離している場合は、実装を尊重して現状把握をおこなう

Coding / 実装

実装やリファクタリング、コードへのドキュメンテーションにおいて、以下のルールを遵守する

• コーディングを行う時は、以下のワークフローを守る
  1. 新しい作業ブランチを作成する
  2. 実装をおこないながら、一定の粒度でコミットする
  3. 修正が完了したらコミットを整理する
  4. 修正後の検証を実施する
• ブランチ名は branch-prefix/task-name の形式で定義する
  • branch-prefix については、指示の先頭または末尾に #branch-prefix の形式で指定があった場合はその値を、指定がなかった場合は yktakaha4 を利用する
  • task-name については、指示の内容を英語で要約したものをケバブケースで設定する
  • 例として、 #task-123 型エラーを修正して と入力された場合、ブランチ名は task-123/fix-type-errors のようになる
• 修正した内容はブランチにコミットする
  • 生成AIでコミットしたことがわかるように、 co-authored-by を追加してください
  • 同じコードベース内の既存の実装に合わせた修正を実施する
  • コミットメッセージの書式については、リポジトリの既存のコミットログを見て踏襲して作成する
  • コミットを行う際には、資格情報や個人情報などの機微情報が変更内容に含まれていないことに十分留意する
• 修正後の検証として、READMEを確認して lint、format、自動テストのコマンド実行を試みてもよいが、コマンドの実行そのものに失敗する（テストのアサーションエラーでなく、実行環境が整っておらずクラッシュしている場合など）場合は、実行を中止して指示を仰ぐ
  • 動作する環境に依存するエラーについて独力で修正しようとしないこと

Reporting / 記録

タスクの実行結果の記録方法において、以下のルールを遵守する

• Markdown形式で記載する
• 内容は箇条書きにし、平易な日本語を使う
• リポジトリ内の実際のソースコードへの相対リンクを細かく記載するのが望ましい
  • 調査結果の格納先を考慮したリンクを作成する。例えば、 dir/subdir/code.py:123-125 を示すリンクは、 [dir/subdir/code.py:123-125](../dir/subdir/code.py#L123) となる
• 調査結果は、${base_dir}/tkhstmp/task_${YYYYMMDD}_${調査概要の英語表現}.md に保存する
  • ${base_dir} は、Gitリポジトリの場合はリポジトリルート、そうでない場合はコーディングエージェントの実行を開始した時の作業ディレクトリ
  • 出力先ディレクトリは mkdir -p tkhstmp/ 相当の操作で作成する
  • ファイルやディレクトリは読み取り後に他者によって変更される可能性がある。書き込みを試みる前に再度読み込みをおこなう
• 生成した記録はローカルディレクトリ tkhstmp/ に保持すればよく、gitへのコミットは不要です

記録の出力形式を以下に示す

# ${作業概要の日本語表現}

- 作業日: ${記録の出力時刻}
- Git: ${ブランチ名} ${コミットSHA}

## まとめ

${3行程度の箇条書きで記録の要約を記載する}

---

${ルールを遵守する範囲で自由に記述する}