cs-build-getting-started

CodeSpring を使い始める

接続して、プロジェクトの状態を伝え、次のステップを1つ挙げます。簡潔に伝えて、あとは引き継ぎます。

codespring スキルの references/project-state.md（状態の検出、5つの質問、3つの段階）、references/pitfalls.md、および scripts/（決定論的な状態検出）を使用します。

ステップ 1 — 接続する

1. CLI はインストールされていますか？ codespring が見つからない場合：npm i -g @codespring-app/cli。
2. 認証済みですか？ codespring auth status を実行します。認証されていない場合は、codespring auth login を実行するよう依頼して、完了を待ちます。（これを実行すると、期限切れのトークンも更新されます。）
3. プロジェクトはリンクされていますか？ codespring status。
   • リンク済み → 名前を控えて続行します。
   • 未リンク → 既存のプロジェクトをリンクする（codespring projects → codespring init --project <id> --force）か、新規作成します。チームのワークスペースに作成する必要がある場合は、まずウェブアプリで作成してもらいます — project create は --org を無視し、CLI からプロジェクトを移動または削除する方法はありません（pitfalls.md）。
   • 有効なプロジェクトは常にローカルの .codespring/config.json を信頼し、projectId を出力します。

ステップ 2 — プロジェクトの状態を伝える

CLI の出力を目視で確認するのではなく、状態検出のスクリプトを実行します。要約は実行するたびに同一である必要があります。スクリプトはこのスキルと一緒にインストールされる codespring スキル内にあります。そのため、パスはこのスキルのフォルダーからの相対パスです。作業ディレクトリはユーザーのリポジトリになるので、まず絶対パスに解決してください。

bash ../codespring/scripts/fetch-project.sh --out /tmp/cs-state   # read-only snapshot; prints the projectId
node ../codespring/scripts/state.mjs /tmp/cs-state                # the one-line summary + the counts

次に、1行で報告します。

ワークスペースとして接続済み、プロジェクトは名前 — コア機能 6 件、サブ機能 25 件、ノート 6 件、PRD 0 件、タスク 0 件。監査：未実施。

この1行が、このスキルの要点です。ユーザーがすでに持っているものを伝えることで、どのスキルを実行すべきか迷わずに済みます。

ステップ 3 — 次のステップを1つ挙げる

project-state.md の分岐表を使います。選択肢を並べるのではなく、推奨するのは1つだけです。 プロジェクトにすでにマップ、ノート、PRD、またはタスクがある場合は、その表に従って次のステップを選びます。最初からやり直してはいけません。

プロジェクトが空の場合、確認するのは2つだけです。コードがあるか？ そして、ある場合は そのコードは目的を果たしているか？ 2つ目は project-state.md にある5つの質問による診断です。「信用できますか」とは尋ねず、以下を確認してください。

1. アプリは本当に必要なことを実行できていますか？
2. 間違った結果を出したり、作り出した数値や検証できない数値を事実として提示したりしていませんか？
3. 現在のアーキテクチャで、必要なことを実行できますか？
4. 規模を拡大しながら構築できますか？
5. ユーザーが、壊さずに使えますか？

回答	次のステップ
5つの質問のうち1つでも「いいえ」	cs-build-audit-codebase — 問題を診断し、修正にかかるコスト順に並べた平易な説明の問題リストと、再構築か修正かの判定を得ます（実際のユーザーがいる場合、それだけで再構築を見送る理由になりえます）。続けてマップとタスクを作成します。
5つすべて「はい」	cs-build-import-codebase — 実際のコードをコア機能にマッピングし、ノートとPRDを作成します。（コードに問題がありそうな場合は、監査も提案されます。）
まだコードはなく、アイデアの段階	cs-build-plan-app — コードがまだない場合に、インポートの代わりとなるスキルです。ユーザーにインタビューし（または通話の録音を分析し）、画面を順に確認し、機能に基づいてプラットフォームを選び、難所を1つ特定して、その分野の実績ある先行事例を探し、販売可能な v1 に絞り込みます。その後、何かを書く前に計画全体を読み上げ、承認を得ます。マップとノートはこのスキルが作成し、その後 cs-build-create-prd に引き継ぎます。

「コードが実行できる」ことと「コードが目的を果たす」ことは同じではありません。 雰囲気でコーディングされたアプリは問題なく実行できても、質問1〜3に失敗することがよくあります。「動きます」を5つすべて「はい」とみなしてはいけません。ユーザーが知識に基づいて回答できない場合（ほとんどのユーザーはできません）、project-state.md にある簡易ヘルスチェックを実施し、証拠に基づいて回答します。「アプリの診断が必要なときによく見られる6つの兆候のうち4つがあります」のように伝えてから、ユーザーに選んでもらいます。

「間違った」ものを選んでも問題ありません。どのスキルも開始時に実際の状態を検出し、適切な次のステップを実行します。

残りの流れ

メモ付きのマップができたら、次の順に進めます：cs-build-ui-mockup → cs-build-create-prd → cs-build-create-tasks → cs-build-feature → cs-build-resync-codebase。

cs-build-ui-mockup は PRD の前に実施し、ユーザーインターフェースのあるものでは省略できません。 メモをもとに使い捨てのクリック可能なモックアップを作成し、文章による計画では表現できない画面の順序、階層、位置、選択肢の不備を見つけるレビューを実施します。誰も確認していない計画から生成した PRD は、誤解をより詳しく書き起こすだけです。Understand ではコンテキスト（マップ＋メモ）を作成し、Plan では指示（PRD＋タスク）を作成します。PRD の品質は、参照するメモ（project-state.md）の品質に左右されます。

うまくいっている状態

• まず、正しい ローカル プロジェクトに対して認証と接続が済んでいます。1 つのアプリに 2 つのプロジェクトが存在する場合は、どちらが正規のものかユーザーに伝えています（project-state.md）。
• 手作業で数えるのではなく、スクリプトの出力に基づいて、プロジェクトの実際の場所をユーザーに 1 行で伝えています。
• 振り分けは「信頼していますか」ではなく、5 つの質問に基づいています。また、「動作します」は 5 つすべてへの「はい」として受け入れていません。
• 次のステップを 1 つだけ提示し、それがプロジェクトの実際の状態に合っています。選択肢を大量に並べていません。