mcpField
C
cs-build-handoff

cs-build-handoff

github.com/codespringapp開発151 回インストール3 週間前に更新
リポジトリ

cs-build-handoff について

cs-build-handoffは、完成したプロジェクト計画を、主に非技術者のクライアント向けの平易な引き継ぎ資料にまとめるCodeSpringスキルです。計画資料の不足を確認し、作業や未決事項を説明して、引き継ぎ内容をCodeSpringに記録します。

主な機能

  1. 01引き継ぎ前に計画の完成度を確認
  2. 02機能を平易な言葉で説明
  3. 03作業をフェーズごとに整理
  4. 04前提と未決事項を明記
  5. 05具体的な次の手順を提示
  6. 06引き継ぎ内容をCodeSpringに記録

活用シーン

  1. 01完成した開発計画をクライアントに提示
  2. 02モックアップ、工程、後回しの範囲を説明
  3. 03着手に必要なクライアントの判断を特定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/codespringapp/codespring-skills --skill cs-build-handoff

インストール後、Claude Code で/cs-build-handoffを入力して読み込まれたか確認します。

詳細

計画を引き継ぐ

計画そのものが成果物であるなら、引き継ぎが納品です。 これまでのすべての工程で、構築に向けた成果物として、マップ、メモ、PRD、タスクボードが作られています。どれも費用を支払う人に向けて書かれたものではありません。また、一度も開いたことのないキャンバスへのリンクを渡しても、納品にはなりません。

ここでは、相手が受け取るものを作成します。

マップ、メモ、PRD、タスクがすべてそろったら、cs-build-create-tasksの後に実行してください。

codespringスキルのreferences/project-state.mdとreferences/pitfalls.md、および**cs-build-audit-codebase/references/plain-english-writeup.md**を読んでください。そこにある文章のルールは、ここでもそのまま適用されます。小学3年生にもわかる読みやすさにし、ファイルパス、専門用語、フレームワーク名は使わないでください。


0. 引き継ぐものがそろっているか確認する

bash ../codespring/scripts/fetch-project.sh --out /tmp/cs-state
node ../codespring/scripts/state.mjs       /tmp/cs-state
node ../codespring/scripts/check-map.mjs   /tmp/cs-state

穴のある計画を引き継いではいけません。 次のものが欠けていないか確認し、欠けている場合ははっきり伝えてください。

  • 主要機能。それぞれに具体的なメモがあること
  • すべての主要機能のPRD
  • 番号が付いて順序立てられ、各機能に紐づいたタスク
  • ユーザーインターフェースがある場合はモックアップ

欠けているものを説明から省いて済ませてはいけません。戻って完成させてください。例外は、意図的に先送りした項目だけです。その場合は、黙って記載しないのではなく、**「まだ決めていないこと」**に含めてください。

1. 読む人を理解する

多くの場合、実際にお金を支払っていて、不安を感じている非技術者のオーナーです。以前に依頼した制作会社やプログラムで失敗した経験があることもよくあります。

作り手ではなく、その人に向けて書いてください。 全体のトーンを決めるポイントは2つです。

  • 説明文には専門用語、ファイルパス、フレームワーク名、タスクIDを使いません。 何を受け取るのかを理解するために、PRDとは何かを知る必要はありません。
  • どう作るかではなく、使う人に何ができるかを伝えます。 「彼女が利用時間を選ぶと、アプリがセッションを実行します」ではなく、「セッションコントローラーがワークアウトスキーマを読み込みます」と書いてください。

相手が技術に詳しい場合でも、わかりやすい説明を不快には思いません。逆は当てはまりません。

2. 資料を作成する

1つのドキュメントにまとめます。相手が疑問に思う順に、以下のセクションを並べてください。

何を作るのか

わかりやすい英語で2〜3段落を書きます。できる限り相手自身の言葉を使い、打ち合わせやメモの表現をそのまま取り入れてください。相手が自分のアイデアだとわかり、しかも自分の説明より明確に伝わる内容にします。

何のためのものか、誰のためのものかを伝えてください。ここではまだ機能を列挙しません。

何ができるのか

主要機能を並べ、それぞれについて、使う人が実際に何をできるのかを1〜2文で説明します。マップの構成に合わせるのではなく、相手が使う言葉で名前を付けてください。

モックアップがある場合は、各機能のそばに、その機能を示すスクリーンショットを掲載してください。相手が最も注意深く読むセクションです。

どんなものが見られるのか

モックアップの実行方法またはホスティング先を示し、完成品ではなく、完成したときの見た目を示すスケッチですとわかる一文を添えてください。まだ何も動かず、データは仮のものであり、構築を始める前に見た目を確認して意見をもらうために用意したものです。

スタイルガイドのページがあれば含め、その目的も説明してください。色、書体、余白を一か所で設定しているため、後から見た目を変える場合も、作り直しではなく小さな変更で済みます。

どのように作るのか

タスクリストは、個別のタスクではなくフェーズとしてまとめてください。60行もの一覧を読みたい人はいません。すでにある4〜5つの段階に分け、それぞれについて、何をするのか、およその期間、完了すると何ができるようになるのかを説明してください。

ここでは、次の2点を正直に伝えます。

  • 難しいところを明示し、画面を作り込む前にまず検証すると説明します。 計画の最初のタスクがスパイクなら、その理由を1文で説明してください。
  • 相手に対応してもらうことを明示します。 コンテンツ、判断、レビュー、アカウントなどです。ここは最も省かれやすいセクションであり、構築が止まる最も一般的な原因でもあります。

実際に合意していない限り、納品の総日程は提示しないでください。 全体の流れと順序を示してください。

想定していたこと

相手に代わって立てた想定をすべて、平易な言葉で、それぞれ一行の理由とともに記載します。プラットフォーム、対象範囲、想定読者、v1 から除外したものなど、あらゆる項目が対象です。

このセクションは信頼を損なうのではなく、築くためのものです。相手が異議を唱える想定は、今なら簡単に修正できますが、開発後では修正に大きなコストがかかります。また、想定を明らかにすることが、計画と単なる当て推量を分けます。

まだ決めていないこと

本当に未解決の質問と、それぞれに回答する必要がある人を記載します。決定によって何が可能になるのかを具体的に示してください。「コンテンツ作業を始めるには、エクササイズのリストが必要です」は対応可能な内容ですが、「未定」では不十分です。

最初のバージョンに含まれないもの

それぞれに理由を添えて明示し、「決して対応しない」ではなく「後で対応」とはっきり示します。除外項目を明言しないと、相手が完成物を見た瞬間に、約束を破られたと受け取られます。

次にすること

番号付きで、具体的かつ簡潔にします。通常は次のとおりです。

  1. 計画を開く(リンク)
  2. モックアップを見る(リンクまたはコマンド)
  3. 「まだ決めていないこと」に記載された項目を返信する
  4. ビルドツールでプロジェクトを開き、最初のタスクに着手する

相手がこれらのツールを一度も使ったことがないと想定してください。説明だけでなく、実際のリンクと実際の最初のタスクを含めてください。

すべての資料の場所

計画へのリンク、モックアップ、ドキュメント、タスクボード、問い合わせ先を簡潔にまとめます。

3. 相手が実際に読む形式で届ける

相手に尋ねるか、相手について知っていることを参考にします。ドキュメントの内容は同じですが、届け方は異なります。

  • レンダリングされたページなら、開いて共有できます。通常はこれが最適な選択肢で、スクリーンショットを本文内に配置できます。
  • Markdown ファイルなら、リポジトリ内に置きます。相手がリポジトリに慣れている場合に適しています。
  • メールまたはメッセージ本文なら、資料が短く、リンクをクリックするより受信トレイで読む可能性が高い場合に適しています。

どの形式でも、**スクリーンショットを含めてください。**画像のない計画は請求書のように読まれますが、画像のある計画は製品のように読まれます。

4. CodeSpring に記録する

次のセッションで、クライアントにすでに伝えた内容がわかるようにします。

  • プロジェクトの説明を、平易な言葉で書いた「何を作るのか」の段落に設定します。そうすれば、キャンバスを開いたときに、相手が見覚えのある内容が表示されます。
  • 引き継ぎの日付と送付した内容を、プロジェクト情報またはメモに記録します。
  • 想定や未解決の質問を記載した場合は、関連する機能のメモにも必ず記載します。そうしないと、誰も再び読まないドキュメントにしか残りません。
codespring mindmap set-info --title "..." --description "<the plain-English paragraph>"

5. 送った内容を伝える

依頼した人に、通常はクライアントとは別の人に、次の3点を伝えます。送付した内容、クライアントからの返答待ちの内容、返答が届いた後に行うことです。


良い成果物の条件

  • クライアントが資料一式を最後まで読み、自分のアプリについて別の人に説明できること。
  • 説明文には、専門用語、ファイルパス、タスク ID、フレームワーク名を一切含めないこと。
  • モックアップのスクリーンショットを含め、該当する機能のそばに配置すること。
  • 開発順序は、60 行にわたる一覧ではなく、何が可能になるかを示したフェーズで表すこと。
  • 想定を明記し、それぞれに理由を添えること。
  • 相手に対応してもらうことを具体的に示し、それによって何が可能になるかを説明すること。
  • 除外項目は「後で対応」として明記し、何も言わずに除外しないこと。
  • 次の手順に番号を付け、実際のリンクと実際の最初のタスクを示すこと。
  • 平易な言葉で書いた概要を CodeSpring プロジェクトに記載し、キャンバスを開いたときに、相手が見覚えのある内容が表示されるようにすること。

コメント