agentleFS
mae616mae616/ai-template/.claude/skills/project-init/SKILL.md

project-init

Skill9 starsChanged 3 months agoMITView on GitHub

壁打ちから要件定義、ボイラーテンプレート作成、AIテンプレート適用までを一気通貫で実行する。新規プロジェクトの立ち上げで使う。

  • Reads credentials

38 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use harness-audit, workflow and 3 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • sattva2020Skill

    harness-audit

    Audits a codebase for "AI-agent harness" maturity across six layers (context engineering, tools & MCP, memory & state, tests & evals, observability, guardrails & approvals). Scores each layer, flags AGENTS.md/CLAUDE.md drift, gives prioritized fixes. Use for "audit harness", "оцени харнес", "check agent readiness", "is this project agent-ready", "проверь готовность к AI-агентам".

    Also in 3 projects that use this

  • VercelSkill

    workflow

    Creates durable, resumable workflows using Vercel's Workflow SDK. Use when building workflows that need to survive restarts, pause for external events, retry on failure, or coordinate multi-step operations over time. Triggers on mentions of "workflow", "durable functions", "resumable", "workflow sdk", "queue", "event", "push", "subscribe", or step-based orchestration.

    Also in 3 projects that use this

  • MicrosoftSkill

    release

    Use ONLY when the user explicitly asks to cut/publish a Huabu desktop release or tag a version. Performs an outward action — bumps the version in apps/desktop/package.json, commits + annotated-tags vX.Y.Z, and pushes the branch + tag. That tag push auto-builds the macOS/Windows installers and publishes a GitHub Release. Provides `status`, `bump`, `tag-push`, and a one-command `run` (bump → tag-push).

    Also in 4 projects that use this

  • MicrosoftSkill

    handoff

    Compact the current conversation into a handoff document for another agent to pick up.

    Also in 3 projects that use this

  • GoogleSkill

    code-review

    Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.

    Also in 3 projects that use this

The file

Files
SKILL.md

[プロジェクト] 新規プロジェクト初期化

入力:

  • プロジェクトの概要(任意)
  • 省略時: 壁打ちから開始

例: 新しいポートフォリオサイトを作りたい SaaSダッシュボードを始めたい Astro + Svelte でブログを作りたい


🎯 目的

  • 要件定義からプロジェクト作成までを壁打ちしながら一気通貫で実施
  • ボイラーテンプレートの作り方を毎回調べる手間をなくす
  • ai-template(.claude/ CLAUDE.md doc/)を自動適用し、rdd.md に要件定義を反映した状態で開発を開始

Phase 0: テンプレートソースの検出

このスキルは ai-template ディレクトリ内から実行しても、グローバルスキルとしてどこからでも実行しても動く。

検出ロジック(AIが自動実行)

# 1. カレントディレクトリが ai-template か確認
if [ -f "./CLAUDE.md" ] && [ -d "./.claude/skills/project-init" ]; then
  TEMPLATE_SOURCE="$(pwd)"

# 2. グローバル設定ファイルから読み取り
elif [ -f "$HOME/.claude/ai-template-path" ]; then
  TEMPLATE_SOURCE="$(cat $HOME/.claude/ai-template-path)"

# 3. よくあるパスを探索
elif [ -d "$HOME/output/ai-template/.claude/skills" ]; then
  TEMPLATE_SOURCE="$HOME/output/ai-template"

# 4. 見つからない → ユーザーに確認
else
  # AIがユーザーにパスを質問する
  echo "ai-template のパスを教えてください"
fi

テンプレートパスの永続化(初回のみ)

見つかったパスを ~/.claude/ai-template-path に保存して、次回以降自動検出できるようにする。 ユーザーに保存の確認を取ること。


Phase 1: 壁打ち(/pair plan と同じ進め方)

/pair スキルと同じ壁打ちスタイルで進める。推測で断言せず、前提・選択肢・トレードオフを言語化する。

適用skill(ガイド)

  • biz-researcher / proposition-reviewer(事業仮説・ターゲットの整理)
  • architecture-expert(技術選定・アーキテクチャ判断)
  • ui-designer(UIが中心のプロジェクトの場合)

進め方(/pair と共通)

ステップ1: 不足情報を短問で確認(1〜3問)

プロジェクト概要を聞き、以下の不足を埋める:

確認ポイントrdd.md の対応セクション
何を作る?誰のため?プロジェクト概要 > 目的・想定ユーザー像
どこで動く?ターゲット表示環境
制約は?(期限/体制/予算)制約

ステップ2: 技術スタックを2〜3案提示(トレードオフつき)

レイヤー選定基準
フロントターゲット環境・インタラクション要件・SSR/SSG要否
バックエンドAPI要件・リアルタイム要否・認証要件
データ永続化要件・スケール・コスト
インフラデプロイ先・CI/CD・コスト
テストテスト戦略(Unit/Integration/E2E)

ステップ3: 推奨案と理由

採用する技術スタックの推奨案を、根拠とともに提示する。

ステップ4: rdd.md ドラフト生成 → 次の一手

壁打ちの結果を doc/input/rdd.md のフォーマットに整形する。 この時点ではメモリ上に保持(ファイル書き込みは Phase 3 で行う)。

ドラフトをユーザーに見せて「この内容でプロジェクトを作成しますか?」と確認する。 承認後、Phase 2 へ進む。


Phase 2: ボイラーテンプレート作成

2.1 プロジェクト名・ディレクトリの決定

質問:
- プロジェクト名(slug形式)は? 例: my-portfolio, saas-dashboard
- 作成先ディレクトリは? 例: ~/output/, ~/projects/

2.2 ボイラーテンプレートの選定

Phase 1 で決めた技術スタックに基づき、CLI コマンドを提案する。

よく使うボイラーテンプレート一覧

技術スタックCLIコマンド補足
Astronpm create astro@latest対話式。テンプレート選択あり
Next.jsnpx create-next-app@latestApp Router/Pages Router選択
Remixnpx create-remix@latestテンプレート選択あり
SvelteKitnpx sv createテンプレート選択あり
Vite + Reactnpm create vite@latest -- --template react-ts軽量。SPA向き
Vite + Sveltenpm create vite@latest -- --template svelte-ts軽量。SPA向き
Vite + Vuenpm create vite@latest -- --template vue-ts軽量。SPA向き
Expressnpx express-generatorバックエンド単体
Hononpm create hono@latest軽量エッジバックエンド
T3 Stacknpm create t3-app@latestNext.js + tRPC + Prisma + Tailwind
Turboreponpx create-turbo@latestモノレポ。複数パッケージ管理

上記にない場合は、技術スタックに合った公式 CLI を Web 検索で確認する。

2.3 ボイラーテンプレートの実行

  1. ユーザーにCLIコマンドを提示して確認を取る
  2. 承認後、Bash ツールで実行する
  3. 対話式プロンプトがある場合は、Phase 1 の決定事項を基に選択肢を案内する

注意:

  • CLIの対話式プロンプトは自動応答が難しい場合がある。その場合はユーザーに手動実行を案内する
  • 実行前に必ず ls で作成先ディレクトリの存在を確認する
  • TypeScript を使う場合は TS テンプレートを優先する

2.4 依存パッケージの確認

ボイラーテンプレート作成後:

  1. package.json 等を確認して、追加で必要なパッケージを提案する
  2. Phase 1 で決めた技術スタックに基づき、追加インストールを実行する
  3. Prettier をボイラーテンプレート標準に含める: prettier + 対象スタックの eslint-config-prettier 相当を導入し、設定ファイルを配置する。.claude/hooks/format-on-edit.sh が編集直後に適用するため、後付けの摩擦を避けるべく最初から導入する
  4. テストランナーを最初から導入する: RDD のテスト戦略に従いテストランナー(Vite系なら Vitest 等)を導入し、package.json に test スクリプトとスモークテスト1本(起動確認レベル)を置く。TDD 前提のためタスク1本目からテストが生まれる。CI の Test ゲート(main 向け PR で実行)を最初の PR から緑にするための布石で、「初期開発が終わってからテストを設定する」運用はしない

Phase 3: AIテンプレートの適用

3.1 コピー対象

Phase 0 で検出した TEMPLATE_SOURCE から、以下をコピーする:

コピー元コピー先説明
.claude/skills/.claude/skills/判断軸・手順系スキル一式
.claude/settings.json.claude/settings.jsonClaude Code 設定(存在する場合)
CLAUDE.mdCLAUDE.mdプロジェクトルール
.claude/rules/.claude/rules/運用ルール(自動適用)
doc/input/rdd.md—コピーしない(Phase 3.2 で生成する)

コピーコマンド例

TEMPLATE_SOURCE="/path/to/ai-template"
PROJECT_DIR="/path/to/new-project"

# ディレクトリ構造を作成
mkdir -p "$PROJECT_DIR/.claude"
mkdir -p "$PROJECT_DIR/.claude/rules"
mkdir -p "$PROJECT_DIR/doc/input"

# skills をコピー(既存があればマージ)
cp -r "$TEMPLATE_SOURCE/.claude/skills" "$PROJECT_DIR/.claude/"

# 設定ファイルをコピー(存在する場合のみ)
[ -f "$TEMPLATE_SOURCE/.claude/settings.json" ] && cp "$TEMPLATE_SOURCE/.claude/settings.json" "$PROJECT_DIR/.claude/"

# CLAUDE.md をコピー
cp "$TEMPLATE_SOURCE/CLAUDE.md" "$PROJECT_DIR/"

# 運用ルールをコピー
cp -r "$TEMPLATE_SOURCE/.claude/rules/" "$PROJECT_DIR/.claude/rules/"

3.2 rdd.md の生成

Phase 1.3 で作成したドラフトを doc/input/rdd.md に書き出す。

# rdd.md を Write ツールで生成
# Phase 1 のドラフト内容を doc/input/rdd.md に書き込む

3.3 project-design-language の初期起票

Phase 3.1 でコピーされた穴埋め雛形 .claude/skills/project-design-language/SKILL.md を、judgment-harness の発酵ループに従ってこのタイミングで対話起票する(雛形のまま放置しない):

  1. 基本方針(存在設計の核)だけを対話で埋める: 誰のためのプロダクトか / 何を良しとするか(北極星)/ 単一メタファー宣言。Phase 1 の壁打ち・rdd.md の内容から手がかりを拾い、弱ければ候補提示→人間選定
  2. 固有値レジストリ(色/タイポ/モーション/声)は TBD のままでよい。推測で埋めない
  3. UIを持たないプロジェクト(CLI/ライブラリ等)の場合は、その旨を確認してスキップしてよい(スキップした事実を rdd.md に記録する)

ここで最低限の核を入れておくことで、後続の auto-build / auto-design / creative-coder / deep-review がメタファー参照で動ける状態になる。

3.4 CI セットアップの確認(ユーザーに聞く)

「GitHub Actions で CI をセットアップしますか?」とユーザーに確認する。YES なら .claude/rules/git.md の CI 要件に準拠した .github/workflows/ci.yml を生成する:

# CI要件は .claude/rules/git.md に準拠:
#   task/*, feature_fix/* push  → Lint + TypeCheck
#   main への PR(sprint/hotfix)→ Lint + TypeCheck + Build + Test
name: CI

on:
  push:
    branches: ['task/**', 'feature_fix/**', 'hotfix/**', 'sprint/**']
  pull_request:
    branches: [main]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - name: Build(main向けPRのみ)
        if: github.event_name == 'pull_request'
        run: npm run build
      - name: Test(main向けPRのみ)
        if: github.event_name == 'pull_request'
        run: npm test
  • パッケージマネージャ(npm/pnpm)と scripts 名は、生成したボイラーテンプレートの package.json に合わせて調整する
  • 対応する scripts(lint / typecheck / build / test)が package.json に無い場合は先に追加する(test は Phase 2.4 のテストランナー導入とセット。TDD 前提なので Test ステップも最初から有効にし、後から足す運用はしない)
  • プライベートリポジトリでは GitHub Actions の無料枠を超えると従量課金になる旨を一言添える

3.5 .gitignore の確認

ボイラーテンプレートの .gitignore に以下が含まれているか確認し、なければ追記する:

# セッション一時ファイル
.claude/session-context.md

# 環境変数(セキュリティ)
.env
.env.local
.env.*.local

Phase 4: 初期化完了と案内

4.1 初期コミット

cd "$PROJECT_DIR"
git init  # ボイラーテンプレートが git init 済みでない場合
git add -A
git commit -m "feat: プロジェクト初期化(ボイラーテンプレート + AIテンプレート適用)"

4.2 完了メッセージ

以下を表示する:

✅ プロジェクトの初期化が完了しました!

📁 プロジェクト: {PROJECT_DIR}
🛠 技術スタック: {選定した技術スタック}
📝 要件定義書: doc/input/rdd.md

🚀 次のステップ:
1. 新しいプロジェクトで Claude Code を起動してください:
   cd {PROJECT_DIR} && claude

2. /session-start でセッションを開始してください

3. /task-list でタスクを計画してください

4.3 テンプレートソースの永続化確認

Phase 0 で新たにテンプレートパスを検出/指定した場合:

💡 ai-template のパスを保存しますか?
   保存先: ~/.claude/ai-template-path
   次回から自動検出されます。

出力

  • 新規プロジェクトディレクトリ(ボイラーテンプレート + AIテンプレート適用済み)
  • doc/input/rdd.md(壁打ちの成果が反映済み)
  • 初期コミット

品質チェックリスト

  • rdd.md の「AI用事実ブロック」が埋まっている(技術スタック/ターゲット環境/制約)
  • project-design-language の基本方針(誰のため/北極星/メタファー)が埋まっている(またはスキップ理由が rdd.md に記録済み)
  • .claude/skills/ がコピーされ、スキル一覧で認識される
  • CLAUDE.md がプロジェクトルートに存在する
  • .gitignore にセキュリティ関連(.env等)が含まれている
  • ボイラーテンプレートの依存パッケージがインストール済み
  • 初期コミットが作成されている

自己評価

  • 成功自信度: (1-10)
  • 一言理由: {短く理由を記載}

トラブルシューティング

テンプレートソースが見つからない

# 手動でパスを設定
echo "/path/to/ai-template" > ~/.claude/ai-template-path

ボイラーテンプレートのCLIが対話式で自動実行できない

  • ユーザーに別ターミナルでの手動実行を案内する
  • 完了後にこのスキルの Phase 3 から再開する

既存プロジェクトにAIテンプレートだけ適用したい

  • Phase 2 をスキップして、Phase 0 → Phase 1 → Phase 3 → Phase 4 の順で実行する
  • 「既存プロジェクトにテンプレートを適用したい」と伝えればAIが判断する

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.