@ripla/godd-mcp 1.0.7-canary.9 → 1.0.7

package/templates/notes-docs/006_development_workflow/README.md

@@ -0,0 +1,67 @@
+# 開発の進め方
+
+**日々の開発をどう進めるか**をまとめたフォルダです。エンジニア経験は前提としません。
+
+**毎日見るのは [daily_flow.template.md](./daily_flow.template.md) の1本だけ**です。他は必要になったときに開きます。
+
+---
+
+## 読む順番
+
+| # | ドキュメント | いつ読むか |
+|---|---|---|
+| 1 | [daily_flow.template.md](./daily_flow.template.md) | **毎日これだけ見れば進められる** |
+| 2 | [judgment.template.md](./judgment.template.md) | **手が止まって、進めてよいか迷ったとき** |
+| 3 | [workflow.template.md](./workflow.template.md) | 全体像や、誰が何を担当するか確認したいとき |
+| 4 | [git.template.md](./git.template.md) | ブランチ名やコミットの意味を確認したいとき |
+
+**はじめて参加する人は、まず [../007_guides/getting_started.md](../007_guides/getting_started.md) を先に読んでください。**
+
+---
+
+## 役割別の最短ルート
+
+| 役割 | 読むもの |
+|---|---|
+| **実装担当**（エンジニア経験不問） | [daily_flow.template.md](./daily_flow.template.md) → 進めてよいか迷ったら [judgment.template.md](./judgment.template.md)、エラーが出たら [../007_guides/troubleshooting.md](../007_guides/troubleshooting.md) |
+| PM | [workflow.template.md](./workflow.template.md) の「A. 資料を受け取ったとき」「役割分担」 |
+| レビュアー | [git.template.md](./git.template.md) の「PR 運用」「レビュー観点」 |
+| アーキテクト | [workflow.template.md](./workflow.template.md) 全体 + ADR の運用 |
+
+---
+
+## このプロジェクトの前提
+
+| 原則 | 意味 |
+|---|---|
+| **仕様書が正（SSOT）** | コードと仕様が食い違ったら、仕様書が正しい。**仕様書の更新漏れはバグ扱い** |
+| **1 Issue = 1 ブランチ = 1 PR** | 1つの PR には1つの責務だけを入れる |
+| **`main` に直接 push しない** | 必ず PR とレビューを経由する |
+| **品質ゲートを通してから提出** | 失敗したまま PR を出さない |
+
+---
+
+## 3行でいうと
+
+```text
+1. Issue の番号を AI に渡す   → 実装・テスト・コミットまで自動
+2. どう終わったかを確認する
+3. できていれば、PR を出して人に見てもらう
+```
+
+**AI に打つのはこの3つです。** 順に打つだけで進みます。
+
+```text
+#1234 を実装して
+ドキュメントを合わせて
+PR を出して
+```
+
+詳細は [daily_flow.template.md](./daily_flow.template.md) にあります。
+
+---
+
+## 関連フォルダ
+
+- ガイド・セットアップ: [../007_guides/](../007_guides/)
+- 仕様書: `../003_requirements/`

package/templates/notes-docs/006_development_workflow/daily_flow.template.md

@@ -0,0 +1,303 @@
+# 毎日の進め方
+
+**2日目からは、このページだけを見れば1日が進みます。**
+
+プログラムを書くのは AI です。あなたがやることは3つだけです。
+
+1. **今日やる作業を選ぶ**
+2. **AI にお願いする**
+3. **できたものを見て、人にチェックしてもらう**
+
+> 手が止まったら [judgment.template.md](./judgment.template.md)、言葉が分からなければ [../007_guides/glossary.md](../007_guides/glossary.md)、エラーが出たら [../007_guides/troubleshooting.md](../007_guides/troubleshooting.md) を開いてください。
+>
+> **書き換え前提**: 相談先・連絡手段・稼働時間はプロジェクトごとに違います。参加時に確認して書き足してください。
+
+---
+
+## 1日の流れ
+
+```mermaid
+flowchart TD
+    A[1. 今日やる作業を選ぶ] --> B[2. 最新の状態にする]
+    B --> C[3. AI に作ってもらう]
+    C --> D{4. どうなったか見る}
+    D -->|できた| E[5. PR を出してお願いする]
+    D -->|質問で止まった| F[次の作業へ]
+    D -->|途中で止まった| G[理由を読む]
+    E --> H[6. 直してと言われたら直す]
+    H --> I[7. 終わったと伝える]
+    F --> A
+    G --> A
+    I --> A
+```
+
+**1件あたり1時間弱、1日1〜3件**が目安です。最初は1件で構いません。時間の大半は、AI が作っているのを待つ時間です。
+
+> 所要時間は暫定の置き値です（実測ではありません）。実績が溜まったらチームで書き換えてください。
+
+---
+
+## 1. 今日やる作業を選ぶ
+
+### なぜやるの？
+
+やることは **Issue（イシュー）** という形で1件ずつ用意されています。その中から、今日やるものを1つ選びます。
+
+> **Issue** = 「これをやってください」と書かれた作業の依頼書です。1枚に1つの作業が書いてあり、`#1234` のような番号が付いています。
+
+### やり方
+
+1. GitHub の **Issues** というタブを開く（GoDD Notes を使っているなら、その Issue 画面でも同じです）
+2. **自分の名前が付いているもの**を探す
+3. その中で、**番号がいちばん小さいもの**を選ぶ
+
+番号が小さいものから選ぶ理由は、**あとの作業が前の作業の結果を使っている**ことがあるためです。順番を飛ばすと、できないことがあります。
+
+### これができていれば OK
+
+今日やる Issue の番号（たとえば `#1234`）が決まっている。
+
+### うまくいかないとき
+
+| こんなとき | どうする |
+|---|---|
+| 自分の名前が付いたものが1件も無い | PM に「次に何をやればいいですか」と聞く |
+| 何を作るのか、読んでも分からない | **始める前に聞く**。分からないまま進めない |
+| 「先に #1200 が必要」と書いてある | それは飛ばして、次の番号のものにする |
+
+---
+
+## 2. 最新の状態にする
+
+### なぜやるの？
+
+同じプロジェクトを他の人も直しています。**あなたのパソコンにあるファイルは、前に取ってきたときのまま**です。
+
+古いままで始めると、他の人がもう直した場所をもう一度直してしまい、あとで「どちらが正しいのか」を決める面倒な作業が起きます。それを防ぐために、**先に他の人の変更を取り込みます**。
+
+### やり方
+
+AI エディタ（Cursor / Claude Code / Codex）のチャット欄に、この文字をそのまま打ちます。
+
+```text
+最新の状態にして
+```
+
+### これができていれば OK
+
+「最新にしました」といった返事が来ている。
+
+> **朝いちばんと、数時間パソコンを離れた後は必ず**やってください。
+
+---
+
+## 3. AI に作ってもらう
+
+### なぜやるの？
+
+ここが1日の中心です。**プログラムを書くのは AI**で、あなたは Issue の番号を渡すだけです。
+
+### やり方
+
+チャット欄に、選んだ番号を付けてそのまま打ちます。
+
+```text
+#1234 を実装して
+```
+
+これだけで、AI が下のことを全部やります。**あなたが何か操作することはありません。**
+
+| AI がやること | どういう意味か |
+|---|---|
+| **ブランチ**を作る | 元のファイルを壊さないよう、作業用のコピーを用意すること |
+| テストを書いてから作る | 「こう動いてほしい」を先に書き、そのとおり動くまで直すやり方 |
+| **品質ゲート**を通す | 決まりを守れているかの自動チェック。落ちたら直してから進む |
+| **コミット**する | 作業の区切りごとに、変更を記録として保存すること |
+| 秘密情報が混ざっていないか調べる | 鍵やパスワードが紛れ込んでいないか確認する。見つかると、そこで止まります |
+
+**ここで一度止まります。** この時点では、まだ他の人に何も見えていません。見てもらう準備は手順5 で行います。
+
+**待っている間は、他のことをして構いません。** 終わると結果を教えてくれます。
+
+### これができていれば OK
+
+「何を変えたか」と「次に何をすればいいか」が報告されている。
+
+### 質問の答えをもらっているとき
+
+前に聞いた質問の答えが届いているなら、一緒に渡します。
+
+```text
+#1234 を実装して。金額の上限は10万円との回答をもらいました
+```
+
+答えは Issue にも残るので、あとから「なぜそうしたか」を追えます。
+
+---
+
+## 4. どうなったか見る
+
+### なぜやるの？
+
+終わり方は3通りあります。**どれだったかで、次にやることが変わります。**
+
+| 終わり方 | 報告に出ること | 次にやること |
+|---|---|---|
+| **最後までできた** | 変えた内容と、「次は `godd-docs` と `godd-submit` を実行してください」という案内 | **5 に進む** |
+| **質問があって進めなかった** | 答えを待っている質問 | 次の Issue へ（下を読む） |
+| **途中で止まった** | 止まった理由と**ブランチの名前** | 理由を読む（下を読む） |
+
+### 質問があって進めなかったとき
+
+**失敗ではありません。** 分からないまま作ると間違ったものができるので、AI がわざと止めています。
+
+止まる理由は2つです。**答え待ちの質問がある**か、**先にやるべき Issue がまだ終わっていない**かです。
+
+1. Issue のコメントに理由が書いてあるので読む
+2. **質問は Issue に自動で書き込まれます。** あなたが写す必要はありません
+3. その Issue はいったん置いて、**次の Issue に進む**
+4. 答えが届いたら、それを添えてもう一度お願いする
+
+   ```text
+   #1234 を実装して。金額の上限は10万円との回答をもらいました
+   ```
+
+> **答えを待って止まらないでください。** 待っている間に次を進めたほうが、1日でできる量が増えます。
+
+> Slack を使っているプロジェクトでは、質問はスレッドにも自動で流れます。答えが来ないときだけ催促してください。
+
+### 途中で止まったとき
+
+**作った分は消えていません。** パソコンの中に残っています（この時点では、まだ他の人には見えません）。
+
+1. Issue のコメントに、止まった理由と**ブランチの名前**が書いてあるので読む
+2. 自分で直せそうなら直して、`#1234 を実装して` ともう一度打つ
+3. **理由が分からなければ相談する**（ブランチの名前を伝えてください）
+
+進めていいか迷ったら [judgment.template.md](./judgment.template.md) を見てください。
+
+---
+
+## 5. 見てもらう準備をして、お願いする
+
+### なぜやるの？
+
+手順3 が終わった時点では、**作ったものはまだ自分のパソコンの中だけ**にあります。他の人には見えません。
+
+ここで2つのことをします。**説明書きを実物に合わせる**ことと、**「見てください」というお願いの形にして送り出す**ことです。
+
+> **PR（ピーアール / プルリクエスト）** = 「この変更を入れていいか見てください」というお願いのこと。
+>
+> **レビュー** = 他の人が中身を見ること。**レビュアー**はその人です。
+
+### やり方
+
+手順3 の報告の最後に「次にこれを実行してください」と書かれています。**そのとおりに、チャット欄へ2回打ちます。**
+
+まず、説明書きを実物に合わせます。
+
+```text
+ドキュメントを合わせて
+```
+
+次に、お願いの形にして送り出します。
+
+```text
+PR を出して
+```
+
+これで PR ができ、**URL が報告されます。**
+
+> **2つとも必要です。** 手順3 では自動で行われません。あなたが中身を確かめてから進めるように、あえて分かれています。
+
+### 出したあとにやること
+
+1. 報告に出てきた **PR の URL** を開く
+2. **自分でもざっと眺める**（全部わかる必要はありません。「明らかにおかしい」がないかだけ）
+3. 下の表を見て、2つとも大丈夫か確かめる
+4. レビュアーに「見てください」と声をかける
+
+**PR は最初から見てもらえる状態で作られます。** ボタンを押して切り替える作業は要りません。
+
+| 見ること | どこを見るか |
+|---|---|
+| 自動チェックが**緑**か | PR の画面にチェック欄があります。**赤い×のままお願いしない**（赤いときは [judgment](./judgment.template.md)） |
+| 関係ないファイルが混ざっていないか | **Files changed** というタブ |
+
+### これができていれば OK
+
+PR ができていて、レビュアーに「見てください」が伝わっている。
+
+---
+
+## 6. 直してと言われたら直す
+
+### なぜやるの？
+
+**指摘が付くのは当たり前のこと**です。もっと良くするための作業で、あなたが責められているわけではありません。
+
+### やり方
+
+1. 指摘を読む。**意味が分からなければ、その場でコメントで聞いていい**
+2. 何を直すか分かったら、チャット欄にそのまま打つ
+
+   ```text
+   PR に「〇〇を△△にしてほしい」という指摘が来ました。対応して
+   ```
+
+3. 直した内容は PR に自動で反映されます
+4. 指摘のコメントに「直しました」と返信する
+
+> **納得できないときは、そのまま従わなくていい**です。「なぜそうしたほうがいいのか教えてください」と聞くのは、正しいやり方です。
+
+### これができていれば OK
+
+すべての指摘に返信が付いている。
+
+**指摘が全部片付くと、本物のファイルに入ります。** 「片付く」とは、直したか、直さない理由に相手が納得したかのどちらかです。**入れる操作はレビュアーがやります。あなたはやりません。**
+
+---
+
+## 7. 終わったと伝える
+
+### なぜやるの？
+
+終わったことがチームに伝わらないと、次の作業が回ってきません。
+
+### やり方
+
+チャット欄にそのまま打つと、伝えるための文章を作ってくれます。
+
+```text
+完了報告を作って
+```
+
+伝える相手と方法はプロジェクトによります。**（ここにチームのやり方を書き足してください）**
+
+### これができていれば OK
+
+報告が相手に届いている。
+
+---
+
+## 1日の終わりに確認すること
+
+```text
+□ 詰まった場所があれば、何に詰まったかを残したか（[judgment](./judgment.template.md) の「詰まったら、あとで残す」）
+□ 今日始めた Issue が、それぞれどう終わったかを全部見たか
+□ 質問で止まったものは、その質問が PM に届いているか
+□ 途中で止まったものは、理由を相談したか（自分で分からなかった場合）
+□ 出した PR の「見てください」まで済ませたか
+□ 明日いちばんにやる Issue が決まっているか
+```
+
+**途中で終わっても大丈夫です。** 止めたところから再開できます。日をまたいでも続きから進みます。
+
+---
+
+## 関連ドキュメント
+
+- 判断に迷ったら: [judgment.template.md](./judgment.template.md)
+- ワークフロー全体像: [workflow.template.md](./workflow.template.md)
+- Git 運用ルール: [git.template.md](./git.template.md)
+- はじめてのセットアップ: [../007_guides/getting_started.md](../007_guides/getting_started.md)

package/templates/notes-docs/006_development_workflow/git.template.md

@@ -1,13 +1,35 @@
 # Git 運用ガイド
 
-本ドキュメントは `godd init` で展開される **新規プロジェクトの Git 運用ルール雛形** です。
-ripla の標準ルールを共通化することを目的としており、ブランチ命名・プレフィックス・レビュー要件などプロジェクト固有の差分は本ファイルを書き換えて運用してください。
+**ブランチ名やコミットの意味を確かめたいときに開くページ**です。上から読む必要はありません。
 
-> **書き換え前提**: 本ファイルは「構成と章立ての標準化」を目的とした雛形です。実プロジェクトでの埋め方の参考として [`ripla-inc/saas-box-manage` の `saas-box-docs/007_development/git.md`](https://github.com/ripla-inc/saas-box-manage/blob/main/saas-box-docs/007_development/git.md) も併せて参照してください。
+**ここに書かれた操作を自分の手で行うことはありません。** ブランチもコミットも PR も AI が規則どおりに作ります。
+
+本ファイルは `godd init` で展開される Git 運用ルールの雛形です。ブランチ命名・プレフィックス・レビュー要件などプロジェクト固有の差分は、書き換えて運用してください。
+
+> **書き換え前提**: 本ファイルは「構成と章立ての標準化」を目的とした雛形です。プロジェクトの実態に合わせて書き換えてください。
 > **godd 利用は Optional**: godd を使わなくても本ルールは成立します。godd 利用時の補助は `_(Optional / godd 利用時)_` として補足します。
 
 ---
 
+## このページの読み方
+
+**ここに書かれた操作を、自分の手で行うことはありません。** ブランチもコミットも PR も、AI が規則どおりに作ります（[daily_flow](./daily_flow.template.md) の手順3・5）。
+
+読むのは、次のようなときです。
+
+| こんなとき | 見るところ |
+|---|---|
+| 見慣れない名前のブランチが出てきた | 「ブランチ戦略」 |
+| コミットの `add:` `fix:` が何か知りたい | 「コミットメッセージ」 |
+| PR に何が書かれるのか知りたい | 「PR 運用」 |
+| やってはいけないことを確かめたい | 「禁止事項」 |
+
+> **ブランチ** = 元のファイルを壊さないための作業用のコピー。
+> **コミット** = 作業の区切りごとに、変更を記録として保存すること。
+> **PR** = 「この変更を入れていいか見てください」というお願い。
+
+---
+
 ## ブランチ戦略
 
 `main` を**唯一の安定ブランチ**とし、すべての作業ブランチは `main` から切り、PR を経由して `main` に戻す **GitHub Flow** を採用します。
@@ -15,23 +37,25 @@ ripla の標準ルールを共通化することを目的としており、ブ
 | ブランチ種別 | 命名規則 | 用途 | 派生元 | マージ先 |
 |---|---|---|---|---|
 | `main` | `main` | 安定版（保護ブランチ） | — | — |
-| 機能 | `feat/<topic>-<issue>-<YYYYMMDD>` | 新機能追加 | `main` | `main` |
-| 修正 | `fix/<topic>-<issue>-<YYYYMMDD>` | バグ修正 | `main` | `main` |
+| 機能 | `feat/#<issue>-<topic>-<YYYYMMDD>` | 新機能追加 | `main` | `main` |
+| 修正 | `fix/#<issue>-<topic>-<YYYYMMDD>` | バグ修正 | `main` | `main` |
 | ドキュメント | `docs/<topic>-<YYYYMMDD>` | ドキュメントのみの更新 | `main` | `main` |
-| リファクタ | `refactor/<topic>-<YYYYMMDD>` | 振る舞いを変えない改善 | `main` | `main` |
+| 作り直し（リファクタ） | `refactor/<topic>-<YYYYMMDD>` | 振る舞いを変えない改善 | `main` | `main` |
 | メンテ | `chore/<topic>-<YYYYMMDD>` | 依存更新・設定変更など | `main` | `main` |
-| 自動生成 | `docs/auto-<YYYYMMDD-HHMM>` | ノートエディタ等からの自動コミット | `main` | `main` |
+| 自動生成 | `docs/<ユーザー名>/<YYYY-MM-DD>` | GoDD Notes 等からの自動コミット（ユーザー×業務日で1本） | `main` | `main` |
 | リリース | `release/v<X.Y.Z>` | リリース準備（必要な場合のみ） | `main` | `main` |
 
 ### 命名例
 
 ```
-feat/user-profile-edit-123-20260514
-fix/login-csrf-820-20260514
+feat/#123-user-profile-edit-20260514
+fix/#820-login-csrf-20260514
 docs/requirements-restructure-20260514
 chore/dependabot-bump-fastapi-20260514
 ```
 
+**Issue に紐づくもの（`feat` / `fix`）は Issue 番号を先頭に置きます。** 番号で検索でき、中断した作業を後から見つけられるためです。
+
 ### 保護ルール（`main`）
 
 - **直接 push 禁止**
@@ -62,7 +86,8 @@ chore/dependabot-bump-fastapi-20260514
 | `refactor` | 振る舞いを変えない改善 | `refactor: auth サービスを usecase 層へ分離` |
 | `docs` | ドキュメント更新 | `docs: requirements 章立てを更新` |
 | `chore` | 依存・設定・ツール類のメンテ | `chore: pnpm を v10 に更新` |
-| `test` | テスト追加・修正 | `test: ライセンス発行ユースケースの ut を追加` |
+| `test` | テスト追加・修正 | `test: ライセンス発行の流れのテストを追加` |
+| `remove` | 機能・ファイルの**削除** | `remove: 使われていないバッチ処理を削除` |
 | `perf` | パフォーマンス改善 | `perf: 一覧取得クエリの N+1 を解消` |
 | `revert` | 直前のコミットを取り消し | `revert: "add: ..."` |
 
@@ -89,7 +114,7 @@ add: ライセンス発行のクライアント呼び出しを追加
 update: 一覧画面に発行ボタンを配置
 ```
 
-> _(Optional / godd 利用時)_ 責務が混在している場合は `godd_commit` で責務単位の自動分割と規約準拠のメッセージ生成を行える。
+> _(Optional / godd 利用時)_ 責務が混在している場合は `godd-commit` で責務単位の自動分割と規約準拠のメッセージ生成を行える。
 
 ---
 
@@ -102,8 +127,8 @@ update: 一覧画面に発行ボタンを配置
 | 粒度 | **1 PR = 1 責務**（複数機能を混ぜない） |
 | サイズ | 目安 400 行以下（超える場合は分割を検討） |
 | タイトル | コミットプレフィックスを踏襲（`feat:` / `fix:` / `docs:` 等） |
-| Draft | 着手中は Draft、レビュー依頼時に Ready for Review に変更 |
-| 自己レビュー | PR 作成前に作者が「レビュー観点」セクションを自己確認（_(Optional / godd 利用時)_ `godd_review` で AI 自己レビューを実施） |
+| Draft | 手で PR を作る場合、着手中は Draft にしてよい。**`godd-submit` で出した PR は最初からレビュー可能な状態**で作られるため、切り替えは不要 |
+| 自己レビュー | PR 作成前に作者が「レビュー観点」セクションを自己確認（_(Optional / godd 利用時)_ `godd-review` で AI 自己レビューを実施） |
 
 ### PR 本文テンプレート
 
@@ -123,8 +148,8 @@ update: 一覧画面に発行ボタンを配置
 
 ## 仕様書更新チェック（SDD 必須項目）
 - [ ] 関連する Spec / Requirements（`docs/003_requirements/` 配下）を本 PR で更新した、または更新不要であることを確認した
-- [ ] 仕様書とコードの整合を確認した（_(Optional / godd 利用時)_ `godd_documentation` で要更新箇所検出、`godd_docs_update` で同期）
-- [ ] 設計判断（採択理由・トレードオフ）がある場合は ADR を `docs/005_architecture/adr/` 配下に追加した（_(Optional / godd 利用時)_ `godd_adr` で生成）
+- [ ] 仕様書とコードの整合を確認した（_(Optional / godd 利用時)_ `godd-docs` で要更新箇所検出と同期）
+- [ ] 設計判断（採択理由・トレードオフ）がある場合は ADR を `docs/005_architecture/adr/` 配下に追加した（_(Optional / godd 利用時)_ `godd-adr` で生成）
 
 ## レビュー観点
 - 重点的に見てほしい点
@@ -166,8 +191,35 @@ SemVer（MAJOR.MINOR.PATCH）に従い、後方互換を破る変更で MAJOR
 
 ## 禁止事項
 
-- `main` への直接 push
-- `--force` / `--force-with-lease` を共有ブランチに対して行う
-- `--no-verify` でフックをスキップする（CI が拒否します）
-- API キー・トークン・パスワードのコミット（提出前に secret scan を実施。_(Optional / godd 利用時)_ `godd_check` で機密情報検出を自動化できる）
-- レビュー未通過・CI 未通過の状態でのマージ
+**なぜ禁止なのか**まで書きます。理由が分かれば、判断に迷う場面が減ります。
+
+| 禁止事項 | なぜ |
+|---|---|
+| `main` への直接 push | レビューを経ずに全員の環境へ影響が出る |
+| 共有ブランチへの `--force` / `--force-with-lease` | 他の人の作業履歴が消える。**取り消せない** |
+| `--no-verify` でフックをスキップ | 壊れたコードが入る。CI が結局拒否する |
+| API キー・トークン・パスワードのコミット | 漏洩は取り消せない。**削除しても履歴に残る**（提出前に secret scan を実施） |
+| レビュー未通過・CI 未通過でのマージ | 検証されていない変更が `main` に入る |
+
+> _(Optional / godd 利用時)_ `godd-check` で機密情報検出を自動化できます。判断に迷ったときは [../007_guides/troubleshooting.md](../007_guides/troubleshooting.md) の「やってはいけないこと」を参照してください。
+
+---
+
+## うまくいかないとき
+
+| 状況 | どうするか |
+|---|---|
+| コンフリクトが出た | まず `godd-sync`。解消しなければ [judgment.template.md](./judgment.template.md) |
+| push が拒否された | `main` に直接 push しようとしていないか確認する |
+| どのブランチにいるか分からない | AI エディタに「今どのブランチにいる？」と聞く |
+| 間違えてコミットした | **自分で取り消さず**に [judgment.template.md](./judgment.template.md) を見る |
+
+---
+
+## 関連ドキュメント
+
+- 判断に迷ったら: [judgment.template.md](./judgment.template.md)
+- 開発ワークフロー: [workflow.template.md](./workflow.template.md)
+- 毎日の進め方: [daily_flow.template.md](./daily_flow.template.md)
+- 用語が分からない: [../007_guides/glossary.md](../007_guides/glossary.md)
+- 困ったとき: [../007_guides/troubleshooting.md](../007_guides/troubleshooting.md)