# Kf G Project Bootstrap New Project Rules

> Use this skill when starting a new project and defining baseline repository rules, especially for optional devcontainer setup, mise-first tooling, pnpm security settings, Vite+ workflows, kiso.css adoption, pre-push test gates, and project-local post-edit lint/format hooks that run after AI agent file edits.

- Skill: `melumuccu/kf-g-project-bootstrap-new-project-rules` (Agent Skill, multi-file: 12 files)
- Install (CLI): `npx skillmds@latest add melumuccu/kf-g-project-bootstrap-new-project-rules`
- Raw SKILL.md: https://api.skillmd.com/api/skills/melumuccu/kf-g-project-bootstrap-new-project-rules/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: melumuccu (https://skillmd.com/u/melumuccu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/melumuccu/kf-g-project-bootstrap-new-project-rules

---


# 新規プロジェクト立ち上げルール

この SKILL.md は**入口**。詳細は `references` 配下の該当ファイルを読む。

**重要**: 新規 PJ の **scaffold と設定ファイル作成**は、本 skill の [入口フロー](#入口フロー) を完了し、ユーザがルール適用を承認するまで開始しない。入口フロー中の**プランニング資料**作成は scaffold 禁止の例外とする（形式と配布手順は、併用するドキュメント配布 skill に従う）。

## この skill を使う場面

- 新しい PJ を作る
- 新規リポジトリの初期構成を決める
- devcontainer や mise を含む開発基盤を最初から整える
- frontend の標準 toolchain を決める
- pnpm の supply chain 対策を初期設定へ組み込みたい
- secret scan を初期設定へ組み込みたい
- AI エージェント編集後の lint/fmt 自動実行を初期設定へ組み込みたい
- push 前に全テスト実行で品質ゲートを掛けたい

## 入口フロー

新規 PJ 立ち上げは、次の手順を順に進める。フェーズ 4（scaffold）の承認前に devcontainer 作成・scaffold・設定ファイル追加などの実作業を始めない。

1. **issue を作成する**（まだ無ければ）。description には issue の最小サマリのみ載せる
1. **PJ 概要を仮置きする**。プロンプトと [合理デフォルト](#合理デフォルト) を起点に不足分を埋め、不明点は「要確認」とする。**プランニング資料をユーザへ提示する前に AskQuestion しない**
1. **プランニング資料を作成する**。ルール適用表・要確認・推奨理由を資料本文に載せる（形式は併用するドキュメント配布 skill に従う）
1. **確認済みの資料 URL またはリンクを issue に載せ、ユーザへ先に提示する**。チャットは短いポインタと URL に留め、表全文を貼って質問攻めしない
1. **ユーザが資料を見て判断・返信するまで待つ**
1. **全ルールの適用 / 不適用が確定したら**フェーズ 4（scaffold）に進む

### フェーズ 1: PJ 概要の仮置き

プロンプトに含まれる情報を起点に PJ 概要を仮置きする。未記載項目は質問せず、[合理デフォルト](#合理デフォルト) を適用するか「要確認」とする。

**プランニング資料をユーザへ提示する前に AskQuestion しない。**

把握対象（仮置き用）:

| 項目            | 例                                                        |
| --------------- | --------------------------------------------------------- |
| PJ 名 / 目的    | 社内ダッシュボード、CLI ツール、API サーバ                |
| リポジトリ種別  | 新規 / 既存空リポジトリ / monorepo 追加                   |
| 提供形態        | Web UI / API のみ / CLI / ライブラリ / 複合               |
| 主要言語・FW    | TypeScript, Go, Python など                               |
| frontend の有無 | ブラウザ向け UI を提供するか                                |
| frontend FW     | SvelteKit / React / なし など                               |
| devcontainer    | 利用するか（**デフォルト: なし**）                          |
| 開発環境        | CI 先（GitHub Actions 等）、ローカル runtime 管理方針     |
| CI runner       | `ubuntu-latest` / Mac Studio self-hosted / 混在             |
| 特記事項        | monorepo 構成、既存 toolchain 継続、Vite+ 非採用理由 など |

### 合理デフォルト

プロンプトに未記載の項目は、次を起点に仮置きする。判断不能なものは「要確認」とする。

- **devcontainer**: デフォルトは**不適用**（利用する明示が無ければ導入しない）
- **frontend の有無**: 未記載なら**要確認**
- **frontend FW**: frontend ありと仮定できる場合のみ推定。それ以外は**要確認**
- **CI**: 未記載なら **GitHub Actions** を想定
- **CI runner**: 未記載なら **`ubuntu-latest`** を想定
- **mise 中心運用・gitleaks・pre-commit / pre-push**: 原則**適用**推奨（frontend なし PJ でも backend 向けに調整）
- **pnpm / Vite+ / kiso.css 等 frontend 向けルール**: frontend ありと確定するまで**要確認**または不適用

### フェーズ 2: ルール適用表の作成

[ルール一覧](#ルール一覧) を全件走査し、PJ 概要に基づいて各ルールの**推奨**（適用 / 不適用 / 要確認）を決める。

- **適用**: 条件を満たし、標準方針どおり導入する
- **不適用**: 条件を満たさない、または PJ 方針上不要
- **要確認**: 条件付きルールで、ユーザ判断が必要

**正本はプランニング資料**。ルール適用表・要確認・推奨理由を資料本文に載せる。チャットは短いポインタと確認済みの資料 URL またはリンクのみ提示してよい。

#### ルール適用表（資料本文テンプレート）

プランニング資料本文に載せる表の形式。正本は資料。チャットへ表全文を貼らない。

```markdown
## ルール適用表（確認用）

| ルール        | 条件 | 推奨 | 理由               |
| ------------- | ---- | ---- | ------------------ |
| devcontainer  | オプション | 不適用 | デフォルトはローカル開発。必要時のみ導入 |
| mise 中心運用 | 汎用 | 適用 | tools / tasks 集約 |
| ...           | ...  | ...  | ...                |

### 要確認項目

- frontend の有無: プロンプト未記載のため要確認
- Vite+: frontend ありの場合に適用推奨
```

### フェーズ 3: ユーザ確認・調整

主手段はプランニング資料と issue への返信とする。

1. 確認済みの資料 URL またはリンクをユーザへ先に提示する
1. ユーザが資料を読み、推奨の承認・変更・追加要件を返信するまで待つ
1. 返信を反映して資料を改訂する場合は、併用するドキュメント配布 skill に従い issue を更新する
1. **全ルールについて適用 / 不適用が確定するまで**フェーズ 3 を繰り返す

AskQuestion は、**プランニング資料を提示したあと**かつ **資料本文の要確認では解消できないブロッカーのみ**に限る。**資料提示前・提示と同ターンの AskQuestion は禁止**。

### フェーズ 4: 承認後に作成開始

ユーザがルール適用を承認したら、初めて scaffold と設定ファイル作成に入る。

1. 承認済み表の **適用** 行に対応する参照ファイルを読み、実装する（[読み進め方](#読み進め方)）
1. **不適用** とされたルールに該当するファイル・設定は作らない
1. 完了前に [checklist.md](references/checklist.md) を、承認済みルールに合わせて確認する

承認済み表は作業ログとして短く残す（どのルールを適用 / 不適用にしたか）。

---

## ルール一覧

全ルールを列挙する。フェーズ 2 ではこの表をベースに、PJ ごとの適用 / 不適用を決める。

| ルール                 | 条件                        | 参照                                                        | 概要                                                                 |
| ---------------------- | --------------------------- | ----------------------------------------------------------- | -------------------------------------------------------------------- |
| devcontainer           | オプション（デフォルト: 不適用） | [devcontainer-mise.md](references/devcontainer-mise.md)     | 利用時のみ `.devcontainer/devcontainer.json` を作成。実行場所を統一  |
| mise 中心運用          | 汎用                        | [devcontainer-mise.md](references/devcontainer-mise.md)     | `mise.toml` に tools / env / tasks を集約                            |
| user settings 確認     | devcontainer 適用時         | [devcontainer-mise.md](references/devcontainer-mise.md)     | `dev.containers.*`, `dotfiles.*` を確認し重複設定を避ける            |
| サンプルファイル起点   | 汎用                        | [devcontainer-mise.md](references/devcontainer-mise.md)     | `references/sample-files/` を初期ファイルの起点にする                |
| gitleaks               | 汎用                        | [gitleaks-pre-commit.md](references/gitleaks-pre-commit.md) | secret scan を GitHub Action と pre-commit の両方で導入              |
| self-hosted runner CI  | CI = Mac Studio self-hosted を **適用** | [kf-g-github-actions-self-hosted-runner-label](../kf-g-github-actions-self-hosted-runner-label/SKILL.md) | workflow の `runs-on` を `[self-hosted, <repo-slug>]` に固定。host runner 未登録時は merge 不可 |
| pre-commit / pre-push  | 汎用                        | [gitleaks-pre-commit.md](references/gitleaks-pre-commit.md) | `pre-commit`, `gitleaks` を mise 管理。local hook を有効化           |
| pre-push 全テスト       | コード編集あり              | [pre-push-test.md](references/pre-push-test.md)             | push 前に `mise run test` で全テスト実行。1 件でも失敗したら push 拒否 |
| pnpm 固定              | frontend あり               | [frontend-pnpm.md](references/frontend-pnpm.md)             | package manager を pnpm に固定                                       |
| pnpm supply chain      | frontend あり               | [frontend-pnpm.md](references/frontend-pnpm.md)             | `pnpm-workspace.yaml` にセキュリティ設定                             |
| Vite+                  | frontend あり               | [frontend-vite-plus.md](references/frontend-vite-plus.md)   | build / dev / check / test を Vite+ 流儀に寄せる                     |
| Svelte / SvelteKit     | frontend + Svelte 採用      | [frontend-vite-plus.md](references/frontend-vite-plus.md)   | 最新安定版を使用                                                     |
| kiso.css               | frontend UI あり            | [frontend-vite-plus.md](references/frontend-vite-plus.md)   | reset CSS を pnpm で導入し entry で最初に読み込む                    |
| Oxlint / Oxfmt         | frontend あり               | [lint-fmt-hooks.md](references/lint-fmt-hooks.md)           | frontend の linter / formatter。未対応時は代替を調査                 |
| lint / format コマンド | コード編集あり              | [lint-fmt-hooks.md](references/lint-fmt-hooks.md)           | `package.json` scripts と `mise run` task に載せる                   |
| 編集後 lint/fmt hooks  | コード編集あり              | [lint-fmt-hooks.md](references/lint-fmt-hooks.md)           | AI エージェント編集後に project hooks で lint/fmt 実行               |
| Tab 補完後 hook        | コード編集あり + ツール対応 | [lint-fmt-hooks.md](references/lint-fmt-hooks.md)           | 利用ツールが対応していれば設定（任意）                               |
| mise 日常 task 一式    | 汎用                        | [devcontainer-mise.md](references/devcontainer-mise.md)     | install / dev / check / test / build / lint / format / hooks-install |

### 条件の読み方

| 条件                        | 適用判定                                                                |
| --------------------------- | ----------------------------------------------------------------------- |
| 汎用                        | 原則すべての新規 PJ で適用推奨                                          |
| オプション（デフォルト: 不適用） | 標準では不適用。ユーザが明示的に利用を選んだ場合のみ適用           |
| devcontainer 適用時         | devcontainer ルールが **適用** と確定している場合のみ適用               |
| frontend あり               | ブラウザ向け UI または frontend パッケージを含む                        |
| frontend UI あり            | ユーザー向け画面・スタイルを提供する frontend                           |
| frontend + Svelte 採用      | frontend があり、Svelte / SvelteKit を採用する                          |
| コード編集あり              | ソースコードをリポジトリで管理・編集する                                |
| コード編集あり + ツール対応 | 編集後 lint/fmt hooks を適用し、かつ Cursor 等が Tab 補完後 hook を提供 |
| CI = Mac Studio self-hosted 適用時 | フェーズ 1 で CI runner = Mac Studio self-hosted を選んだ場合のみ **self-hosted runner CI** ルールを適用 |

frontend なし PJ では pnpm / Vite+ / kiso.css / Oxlint・Oxfmt 等 frontend 向けルールは**不適用**。lint / format コマンド・編集後 hooks は backend 言語に合わせて選定して適用する。

## 読み進め方

承認後の実装手順は `references` 側が正本。SKILL.md は入口とルール選定のみ担う。

1. [入口フロー](#入口フロー) を完了する。
1. [ルール一覧](#ルール一覧) で **適用** となった各行の「参照」列のファイルを読み、実装する。
1. 完了前に [checklist.md](references/checklist.md) を、承認済みルールに合わせて確認する。

## 出力方針

- 入口フロー完了前は、**scaffold と設定ファイルの作成**を始めない。プランニング資料の作成と提示は入口フロー中に行う。
- 入口フロー中は、方針説明と確認済みの資料 URL またはリンクの提示に留める。ルール適用表の正本はプランニング資料とする。
- 承認後は方針説明だけで止めず、承認済みルールに対応するファイルを作る。
- 承認済みルール適用表を短く残す。

## 参照ファイル

| ファイル | 読むタイミング |
| --- | --- |
| [checklist.md](references/checklist.md) | フェーズ 4 完了前の最終確認 |
| ルール一覧の各参照 | フェーズ 4 で **適用** 行の実装 |