ClaudeKit エンジニア

Claude Code と ClaudeKit を始める

AIアシスタントから開発パートナーへ。Claudeの動作メカニズムを解説し、実際のユースケースとベスト/バッドプラクティスを通じてEngineer Kitを紹介します。

Section 01

Claude Codeとは?

Claude CodeはAnthropicのagentic コーディング環境です。質問に答えるだけのチャットボットではなく、ファイルの読み込み、コマンドの実行、コードの修正、問題の自律的な解決ができるAIです。あなたは見守るだけで、他の作業に集中できます。

他のツールとの違い

従来のAI Claude Code
自分でコードを書き、AIがレビュー アイデアを説明するだけで、AIが実装する
コードのコピー&ペーストを繰り返す AIが直接ファイルを読み込み・編集
一つひとつ手動でガイドが必要 AIが自律的に探索・計画・実行
ツール使用なし フルアクセス:bash、git、ファイルシステム

Context Window — 最も重要なリソース

Claude Codeにはcontext windowがあり、会話全体(メッセージ、読み込んだファイル、コマンド出力)を保持します。コンテキストが満杯になるとパフォーマンスが低下します——これが管理すべき最も重要な制約です。

Claudeが指示を「忘れる」
以前に伝えたことに従わない
完了済みの作業を繰り返す
既に終わったことをやり直す
CLAUDE.mdを無視する
定義されたルールに従わない

解決策:関連のないタスク間で /clear を頻繁に使用する。

Section 02

ClaudeKitとは?

ClaudeKitはClaude Code用のワークフローテンプレート集で、2つのkitで構成されています:

Engineer Kit 開発ワークフロー(本ガイドの焦点)
Marketing Kit コンテンツ&マーケティングワークフロー(近日公開)

ClaudeKitは有料製品です。その効果とメンテナーの積極的なサポートにより、このキットを強くお勧めします——インターネット上に散らばる無数の設定やワークフローを調べる時間を大幅に節約できます。

ClaudeKitを購入(20%オフ)

Engineer Kit(claudekit-engineer)はClaude CodeをAIアシスタントから開発パートナーへと変えます。独立したアプリではなく、.claude/ フォルダをプロジェクトにドロップするだけです。

Skills
Claudeが呼び出すコマンド:/ck:cook、/ck:fix、/ck:brainstorm
Hooks
イベント発生時に自動実行されるスクリプト
Agents
サブエージェントの役割:planner、researcher、tester
Rules
セッションをまたいで持続するガイドライン

哲学:YAGNI + KISS + DRY

YAGNI
今必要のない機能は実装しない
KISS
シンプルに保つ——最もシンプルな解決策を選ぶ
DRY
同じことを繰り返さない——繰り返しパターンを抽象化
Section 03

インストールと設定

ステップ1:ClaudeKit CLIをインストール

まずCLIをインストールします(1台のマシンにつき1回のみ):

Terminal
npm install -g claudekit-cli
インストールパスピッカー
オプションを選択 → 対応するコマンドを取得
1. プロジェクトの状態
2. 設定スコープ
3. 自動化レベル
4. リリースチャンネル
5. 既存インストール 上級
▸ あなたのコマンド

        

.claude/.claude\ フォルダが既に存在する場合は、init前に手動でバックアップまたはマージしてください。

ck init 実行後のプロジェクト構造
project/
├── CLAUDE.md              Template (customize after)
├── AGENTS.md              Agent definitions
├── .gitignore
├── .repomixignore         Repomix ignore patterns
├── release-manifest.json  Kit version manifest
├── plans/                 Plans directory
├── .opencode/             OpenCode compatibility
└── .claude/               ClaudeKit config
    ├── .ck.json           Kit metadata
    ├── settings.json      Claude Code settings
    ├── metadata.json      Deletion patterns
    ├── statusline.cjs     Statusline config
    ├── .env.example       Environment template
    ├── .mcp.json.example  MCP config template
    ├── agents/            14+ definitions
    ├── hooks/             22+ hooks
    ├── rules/             Workflow rules
    ├── skills/            90+ commands
    ├── scripts/           Utility scripts
    ├── schemas/           JSON schemas
    ├── output-styles/     Response formats
    └── session-state/     Session tracking
Kitが正常にインストールされました

ステップ2:CLAUDE.mdをカスタマイズ

ck newck init(デフォルト「Update everything: Yes」)は CLAUDE.md テンプレートを自動作成します。「Update everything: No」を選択してチェックを外した場合のみ、CKはこのファイルをスキップします。

CKがテンプレートを作成した後、プロジェクトに合わせてさらにカスタマイズできます:

CLAUDE.md (example)
# Project Name ## Build Commands - `npm install` — install dependencies - `npm run dev` — start dev server - `npm test` — run tests ## Code Style - Use ES modules (import/export) - Prefer async/await over callbacks - TypeScript strict mode

200行以下を維持。長いファイルはcontextを消費し、Claudeがルールを見落としやすくなります(遵守度の低下)。重要なことだけ書く:ビルドコマンド、コーディング標準、主要な規約。指示が膨らんだら、@import.claude/rules/内のファイルに分割。

ステップ3:コーディングレベルを設定(任意)

Claude Codeセッション内で、/ck:coding-levelコマンド(引数なし)を実行してインタラクティブセレクターを開き、6つのレベルから1つを選択。または直接設定:/ck:coding-level 3

Claude Code
# インタラクティブセレクターを開く (メニュー 0-5) /ck:coding-level # または直接レベルを設定 /ck:coding-level 1 # Junior mode

代替手段 — Output Styles(ネイティブ):Claude Codeには独自のOutput styles機能があります — /configを実行 → 「Output style」を選択 → メニューから選択。これはClaude Codeの独立した機能で、CKのcoding levelsと似た命名規則を持っています。

メカニズムの違い:

  • /ck:coding-level.ck.jsonに書き込み、guidelinesはSessionStartフックを通じて各セッション開始時に注入されます。
  • Output stylesはシステムプロンプトを直接変更(outputStyle.claude/settings.local.jsonに保存、prompt cacheの安定性を保つため次のセッションから有効)。

どちらか一方を使用 — /ck:coding-level またはネイティブのOutput styles、guidelinesの重複を避けるため両方同時に有効にしないでください。

Level名前スタイル
0ELI5コードを知らない人に話すように説明する
1Junior理由を説明する、メンタースタイル
2Mid-levelデザインパターン、システム思考
3Seniorトレードオフ、アーキテクチャの意思決定
4Tech Leadリスクとビジネスへの影響
5God Mode手取り足取りなし(デフォルト、15年以上の経験者向け)
God Mode(デフォルト)とは

God Modeはあなたがエキスパート(15年以上またはドメインスペシャリスト)であることを前提とします——答えはすでに知っており、検証/セカンドオピニオン/高速入力が必要なだけです。Claudeは戦力増倍器として動作し、教師ではありません。

やること
• デフォルトはコード、散文ではない • 即座にプロダクション品質のコードを提供 • 高度なパターンは説明なし • 深刻な欠陥を見つけたらアプローチに異議を唱える • 重大な問題(セキュリティ、データ損失)のみをフラグ • 簡潔——すべての言葉に意味を持たせる
やらないこと
• 概念/パターン/構文を説明しない • 「こうすれば...」「説明しましょう...」と言わない • 求められない限りコメントを追加しない • 「重要なポイント」「まとめ」「次のステップ」を書かない • 小さな曖昧さについて確認の質問をしない • 手取り足取り指導が必要なように扱わない

Claude Codeが初めてなら、レベル1か2に設定して説明を得てください。God Modeは速度を最適化しますが、Claudeが間違えた時に自分でデバッグできることを前提としています。

Section 04

カスタムRules — .claude/rules/

大規模なプロジェクトでは、すべてを1つのCLAUDE.mdに詰め込むのではなく、.claude/rules/内の複数の小さなファイルに指示を分割します。RulesはYAML frontmatter経由でファイルパスごとにスコープを設定可能——Claudeがパターンに一致するファイルに触れたときのみコンテキストにロードされ、コンテキストスペースを節約します。

.claude/ ディレクトリの構造

Rulesは一部にすぎません——.claude/には多くの種類の設定が含まれています。Project scope(git経由でチームと共有)とGlobal scope(個人、マシンごと)の概要:

プロジェクトスコープ
gitでコミット · チームと共有
./CLAUDE.md              # project instructions (hoặc ./.claude/CLAUDE.md)
./CLAUDE.local.md        # personal — gitignored
./.mcp.json              # MCP servers (team-shared)
./.worktreeinclude       # copy gitignored files vào worktree mới (optional)
./.claude/
├── settings.json        # permissions, hooks, model
├── settings.local.json  # personal — auto-gitignored
├── rules/*.md           # topic rules (path-scopable)
├── skills/<name>/       # /skill-name + bundles
├── commands/*.md        # /command (legacy — prefer skills)
├── agents/*.md          # subagents
├── agent-memory/        # project subagent memory (memory: project)
└── output-styles/*.md   # system-prompt styles
.\CLAUDE.md              # project instructions (hoặc .\.claude\CLAUDE.md)
.\CLAUDE.local.md        # personal — gitignored
.\.mcp.json              # MCP servers (team-shared)
.\.worktreeinclude       # copy gitignored files vào worktree mới (optional)
.\.claude\
├── settings.json        # permissions, hooks, model
├── settings.local.json  # personal — auto-gitignored
├── rules\*.md           # topic rules (path-scopable)
├── skills\<name>\       # /skill-name + bundles
├── commands\*.md        # /command (legacy — prefer skills)
├── agents\*.md          # subagents
├── agent-memory\        # project subagent memory (memory: project)
└── output-styles\*.md   # system-prompt styles
グローバルスコープ
あなたのマシンのみ · コミットされない
~/.claude.json           # app state, personal MCP, UI prefs
~/.claude/
├── CLAUDE.md            # global instructions
├── settings.json        # default settings
├── keybindings.json     # custom shortcuts
├── rules/*.md           # user-level rules
├── skills/              # personal skills
├── commands/            # personal commands
├── agents/              # personal subagents
├── agent-memory/        # subagent memory (memory: user)
├── output-styles/       # personal styles
├── plugins/             # installed plugins (auto-managed)
└── projects/<project>/memory/   # auto-memory (Claude tự ghi)
%USERPROFILE%\.claude.json  # app state, MCP, UI prefs
%USERPROFILE%\.claude\
├── CLAUDE.md            # global instructions
├── settings.json        # default settings
├── keybindings.json     # custom shortcuts
├── rules\*.md           # user-level rules
├── skills\              # personal skills
├── commands\            # personal commands
├── agents\              # personal subagents
├── agent-memory\        # subagent memory (memory: user)
├── output-styles\       # personal styles
├── plugins\             # installed plugins (auto-managed)
└── projects\<project>\memory\  # auto-memory (Claude tự ghi)

パス固有のrules——ファイルパターンでruleのスコープを指定

必要な時だけruleを読み込む

ruleファイルの先頭にYAML frontmatterを追加して適用範囲を制限します。Claudeはglobパターンに一致するファイルを操作している時のみruleをコンテキストに読み込みます——コンテキストの肥大化を防ぎ、各ドメイン(auth、db、UI、tests…)の専門的なガイダンスを維持します。

.claude/rules/typescript-api.md
--- description: TypeScript API conventions applies_to: - "src/api/**/*.ts" - "src/services/**/*.ts" --- # TypeScript API Rules - Dùng zod schema cho mọi request/response body. - Trả Result<T, E> thay vì throw ở service layer. - Auth middleware phải chạy trước validation middleware.
Rulesはガイダンスであり、強制執行ではない

Rules(とCLAUDE.md)は Claudeが読む指示であり、Claude Codeが強制する設定ではありません。指示が矛盾したり曖昧な場合、Claudeは従わない可能性があります。確実な動作を得るには:

  • Hookssettings.json)— ツール呼び出しの前後に実行されるスクリプト
  • Permissions — 特定のツール/コマンドの許可/拒否

CLAUDE.md vs Settings:2つの異なるマージメカニズム

CLAUDE.md + rulessettings.json
コンテキストに連結——global + project + localすべてが読み込まれるキーレベルのオーバーライド——projectがglobalを上書き、localがprojectを上書き
競合時:最後に読み込まれたファイルが優先(last read)配列(permissions.allow)は結合;スカラー(model)は最も具体的な値を使用
Commands ≈ Skills
CommandsとSkillsは現在同じメカニズムを使用しています。新しいワークフローは skills/<name>/SKILL.md を使用してください——SKILL.md + サポートファイル(チェックリスト、スクリプト、参照ドキュメント)をまとめてバンドルします。SkillとCommandが同名の場合、Skillが優先されます。
自動メモリ
Claudeは ~/.claude/projects/<project>/memory/MEMORY.md に自動的にメモを書き込みます(各セッションで最初の200行/25KBを読み込み)。トピックファイルは遅延ロード。切り替え:/memory または autoMemoryEnabled 設定。

違い:CLAUDE.md vs rules/

CLAUDE.md.claude/rules/*.md
プロジェクト全体の共通指示トピック/パスごとに分けたモジュラーな指示
起動時に常にコンテキストに読み込まれるpathsなし:起動時に読み込み · pathsあり:ファイルがマッチした時に遅延読み込み
目標:200行未満1ファイル1トピック(code-style.md、testing.md...)
ビルドコマンド、全般的な規約ドメインルール:API、フロントエンド、セキュリティ、DB...
単一ファイル複数ファイル、再帰的サブディレクトリ
パス固有のrules

pathsフィールドのYAML frontmatterを使って、Claudeが一致するファイルに触れた時のみruleを有効にする:

.claude/rules/api-design.md
--- paths: - "src/api/**/*.ts" - "src/server/**/*.ts" --- # API Development Rules - All endpoints must validate input via Zod - Use standard error response format - Include OpenAPI docs comments

pathsフィールドを持たないRulesは無条件で読み込まれます。pathsがある場合、Claudeがパターンにマッチするファイルを読むときにトリガーされます。

Rulesを作成する際のベストプラクティス

DO
• ドメイン/関心事ごとにrulesを分割(i18n-rules.md、testing-rules.md...) • 簡潔に書き、箇条書き/チェックリストを使用——Claudeの解析が速い • Kebab-case、説明的な名前(api-error-handling.md) • 例を含める(良い例 vs 悪い例) • 特定のフォルダに適用する場合は正確なパスを参照
DON'T
• ドキュメントのような冗長なrulesを書かない • CLAUDE.mdとrules/の間でコンテンツを重複させない • YAGNIなもの(1回限りの使用)のためにrulesを作らない

一般的なユースケース

UC1: Multi-language app (i18n)
多言語アプリのために .claude/rules/i18n-rules.md を作成する。
i18n-rules.md
# i18n Rules ## Scope Apply to all user-facing text in src/components/ and src/pages/. ## Rules - Mọi user-visible string PHẢI dùng `t('key')` từ `useTranslation()` - Translation keys tại `src/i18n/{locale}/{namespace}.json` - Support locales: vi (default), en, zh, ja - Key naming: `section.component.element` - KHÔNG i18n: code snippets, entity IDs, technical identifiers ## Khi thêm text mới 1. Thêm key vào `src/i18n/vi/{ns}.json` trước 2. Copy key sang 3 locales còn lại với placeholder 3. Cập nhật `src/i18n/index.ts` nếu tạo namespace mới
UC2: API Error Handling
APIレスポンスにdiscriminated unionパターンを強制する。
api-error-handling.md
# API Error Handling ## Pattern Mọi API call phải wrap trong try/catch, return discriminated union: {ok: true, data} | {ok: false, error} ## Error Types (src/types/errors.ts) - NetworkError, ValidationError, AuthError, ServerError ## UI Display - Toast cho transient errors (NetworkError) - Inline form errors cho ValidationError - Redirect to /login cho AuthError
UC3: Database Migration Safety
DB移行時の破壊的変更を避ける。
db-migration.md
# Database Migration Rules - NEVER drop columns trong migration — mark deprecated trước, drop ở release sau - Mọi migration phải có `up()` VÀ `down()` — rollback-safe - Index concurrent (Postgres: `CONCURRENTLY`) cho tables > 10k rows - Test migration trên copy of prod data trước khi merge
UC4: Testing Standards
テストのカバレッジ目標と規約。
testing-rules.md
# Testing Rules ## Coverage - Unit tests cho business logic: > 80% - Integration tests cho API endpoints - E2E tests cho critical user flows (login, checkout) ## Conventions - Test files: `*.test.ts` cạnh source file - Arrange/Act/Assert pattern - Dùng factories thay vì fixtures hardcode - Mock external services, KHÔNG mock internal modules
UC5: Security Baseline
すべてのプロジェクトのベースラインセキュリティrules。
security-rules.md
# Security Rules - NEVER log secrets, tokens, passwords - Input validation: Zod schema at API boundary - SQL: prepared statements only, no string concat - Auth middleware check trên mọi protected route - CORS whitelist từ env, không wildcard - Dependencies: audit weekly với `npm audit`

読み込み順序

セッションを開くとき、Claudeは上から下の順にメモリファイルを読み込み、すべてをコンテキストに連結(concatenate)します——互いに上書きしません。

1 ~/.claude/CLAUDE.md Global user instructions — áp cho mọi project 2 <project>/CLAUDE.md + CLAUDE.local.md Walk-up từ CWD lên project root, nối tất cả lại 3 ~/.claude/rules/*.md → <project>/.claude/rules/*.md Project rules ưu tiên cao hơn user rules khi trùng topic 4 ~/.claude/projects/<project>/memory/MEMORY.md Auto-memory do Claude tự ghi (200 dòng hoặc 25KB đầu tiên) ⇢ Session context (concatenated)

paths frontmatterを持つrulesは、Claudeがパターンに一致するファイルに触れた時のみ有効になります——起動時には読み込まれません。これにより、CLAUDE.mdを肥大化させることなく、各ディレクトリに固有のruleを書くことができます。

推奨サイズ

Anthropicは CLAUDE.mdを200行未満にすることを推奨しています。それより長いファイルは adherence(遵守度)を低下させます——つまり、処理する情報が多すぎるため、Claudeがルールを見落としたり無視したりすることが増えます。ルールファイルも短く保つべきです。CLAUDE.mdが200行に近づいたら、.claude/rules/ にトピック別に分割してください(例:api-design.mdtesting.mdsecurity.md)。チームとClaude両方がGrepで素早く見つけられるよう、説明的なファイル名をつけてください。

高度なファイル読み込みメカニズム

大規模なプロジェクトや複数のリポジトリ間でrulesを共有したい場合、4つのコンテキスト拡張メカニズムがあります。以下の図は、各メカニズムがどのようにベースのCLAUDE.mdに追加ファイルを取り込むかを示しています。

CLAUDE.md Session context (điểm neo chính) @import Nhúng file khác (tối đa 5 hop) --add-dir Mở thêm thư mục vào session CLAUDE.local.md Ghi đè cá nhân (git-ignored) Symlinks Chia sẻ rule giữa nhiều repo
@import syntax 他のファイルをCLAUDE.mdに直接埋め込む

CLAUDE.mdに @docs/coding-standards.md または @~/.claude/my-prefs.md と書くと、その場所にファイルの内容を埋め込めます。Claudeは相対パスと絶対パスの両方をサポートし、最大 5回のネストされたインポート(ホップ)が可能です。長いコンテンツを別ファイルに分割しながら、CLAUDE.mdを簡潔に保つために使用します。

CLAUDE.md
@docs/coding-standards.md @~/.claude/rules/security.md @.claude/rules/testing.md
--add-dir flag 同じセッションで追加の作業ディレクトリを開く

デフォルトでは、Claude Codeは起動したディレクトリ(作業ディレクトリ)のファイルのみを読み込みます。--add-dirフラグを使うと、同じセッション内で追加のディレクトリを開けます——monorepoの作業や、現在のプロジェクト外の ../shared../design-system などのディレクトリを参照する際に便利です。

3つの有効化方法はすべて同等です:起動時の --add-dir フラグ、セッション中のスラッシュコマンド /add-dir、または settings.json での additionalDirectories 宣言。

Kích hoạt --add-dir
# Flag khi launch claude --add-dir ../shared --add-dir ../design-system # Hoặc slash command trong session /add-dir ../shared

重要な注意:デフォルトでは、Claudeは --add-dir で追加したディレクトリから CLAUDE.mdCLAUDE.local.md を読み込みません——古いプロジェクトとの後方互換性を維持するためです。これらのディレクトリからmemoryを適用したい場合は、起動前に以下の環境変数を有効にしてください:

Bật nạp memory cho --add-dir
export CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 claude --add-dir ../shared

有効にすると、追加ディレクトリ内のすべての CLAUDE.md または CLAUDE.local.md がメインプロジェクトと一緒に読み込まれ、同じセッション内で各ワークスペースの規約をClaudeが理解できるようになります。この機能はバージョン 2.1.20 から利用可能で、後方互換性の理由からオプトインです。

CLAUDE.local.md 個人用メモ、gitにコミットしない

プロジェクト内での個人的な設定用ファイル(サンドボックスURL、テストアカウント、個人デバッグコマンド)。CLAUDE.local.md.gitignoreに追加してコミットから除外してください。ClaudeはこのファイルをCLAUDE.mdと一緒に読み込みますが、あなたのマシンでのみ表示されます——チームメンバーには見えません。

シンボリックリンクでrulesを共有 複数のプロジェクトで1つのルールセットを共有

.claude/rules/ディレクトリはシンボリックリンクをサポートしています——チームの標準ルールセットを1か所に保持し、各プロジェクトにリンクします。ruleを更新すると、すべてのプロジェクトが同時に更新を受け取ります。Claudeは循環シンボリックリンクを自動的に検出してスキップし、無限ループになりません。

Share rules qua symlinks
ln -s ~/shared-claude-rules .claude/rules/shared ln -s ~/company-standards/security.md .claude/rules/security.md
Section 05

初心者向け7つのコアコマンド

/ck:brainstorm
コミットする前に解決策を探索。出力:トレードオフ分析、pros/cons、推奨事項。
/ck:brainstorm How should we implement real-time notifications? WebSockets vs SSE vs polling?
/ck:plan
複雑な機能の詳細計画。調査 → 計画 → ファイルリスト → 成功基準。
/ck:plan Implement user authentication with OAuth2 (Google, GitHub)
/ck:cook
実装のメインコマンド。8ステップのワークフロー:調査 → レビュー → 計画 → レビュー → 実装 → レビュー → テスト → 完了。
/ck:cook Add a logout button to the navbar

--fast: Skip research | --auto: Skip all review gates

/ck:fix
7ステップのプロセス(0-6):モード選択 → 調査 → 診断 → 複雑さ → 修正 → 検証 → 完了。
/ck:fix Users can't login after session timeout - seeing "Invalid token" error
/ck:ask
技術的な質問をする。シニアエンジニアが隣にいるようなもの。
/ck:ask How does our authentication middleware handle token refresh?
/ck:test
テストを実行。複数のテストランナーをサポート。
/ck:test src/auth/ # Test specific folder
/ck:watzup
セッションの変更をレビュー。変更されたファイル、git diffの分析、影響評価。
/ck:watzup
Section 06

実際のユースケース

1
新機能を構築する(初心者)
ダークモードのトグルと通知設定を含むユーザー設定ページを追加する。
Full Workflow
/ck:brainstorm User settings page: dark mode + notifications. Should we store in localStorage or backend? Component structure? # → Output: plans/reports/brainstorm-260414-user-settings.md /ck:plan Implement per brainstorm report at plans/reports/brainstorm-260414-user-settings.md # → Creates implementation plan with phases /ck:cook plans/260414-xxxx-user-settings/plan.md # Execute: implement → review → test → done /ck:git cm # Commit with message
適切な計画で機能完成。コードレビュー済み、テスト済み、コミット済み。
2
バグを素早く修正する(初心者)
メールアドレスが無効な場合にフォームバリデーションがエラーメッセージを表示しない。
Quick Fix Workflow
/ck:fix Email validation in signup form doesn't show error message. File: src/components/SignupForm.tsx Expected: "Invalid email" appears below input Actual: No message, just red border /ck:test src/components/SignupForm.test.tsx
リグレッションテスト付きでバグ修正。自動パイプライン:調査 → 診断 → 修正 → テスト → 検証。
3
新しいコードベースにオンボード(中級)
新しいチームに参加し、コントリビュートする前にコードベースを素早く理解する必要がある。
Exploration Workflow
/ck:scout src/ # Explore structure /ck:ask How does the authentication flow work? /ck:ask Explain src/services/auth/token-handler.ts /ck:ask What patterns does this codebase follow?
ドキュメントを2日かけて読む代わりに、30分でアーキテクチャ、主要フロー、パターンを把握。
4
安全なリファクタリング(中級)
500行のレガシーモジュールをクリーンアップする必要があるが、既存機能が壊れるのが怖い。
Safe Refactor Workflow
/ck:ask Analyze src/legacy/user-manager.js What are the hidden dependencies? Side effects? /ck:plan Refactor user-manager.js into smaller modules. Must maintain all existing behavior. Write tests first. # → Creates implementation plan with phases /ck:cook <plan-path> # Execute: implement → review → test → done /ck:code-review # Verify no regressions
モジュール化されたコード、テスト付き、ゼロリグレッション。自信を持ったリファクタリング。
5
FigmaからUIを構築する(中級)
PMからFigmaのモックアップが届き、アニメーション付きでピクセルパーフェクトに実装する必要がある。
UI Implementation Workflow
/ck:frontend-design [paste Figma URL hoặc screenshot] # Auto-activates /ck:ui-ux-pro-max (design intelligence) # Claude generates với đúng spacing, colors, animations /ck:ui-styling Add dark mode support cho component vừa tạo /ck:test src/components/NewFeature.test.tsx
ピクセルパーフェクトなUI、レスポンシブ、ダークモード付き。デザイナーの再レビューが不要。
Section 07

ベストプラクティス

DO: Claudeに結果を検証する方法を与える

最も影響力のある単一のヒント。

Bad
implement email validation
Good
write validateEmail function. Test cases: user@example.com → true Run tests after implementing.

DO: ブレインストーム → 計画 → Cook

/ck:brainstorm [explore options]
/ck:plan [detail implementation]
/ck:cook [implement + test]
/ck:git cm [commit]

/ck:cookにはテストが含まれています。特定のフォルダをテストする場合のみ/ck:test [path]を個別に使用してください。

/ck:brainstorm をスキップするのはいつ?

以下の場合は /ck:plan を直接使う:

  • アプローチが明確な場合(特定のバグ修正、仕様に従ったエンドポイント追加)
  • シンプルなタスクで代替案を探索する必要がない場合
  • FigmaやPRDからのデザイン/仕様が既にある場合

以下の場合は /ck:brainstorm を先に使う:最善のアプローチが不明、トレードオフ分析が必要(WebSockets vs SSE)、前例のない新機能。

UI機能:実装前にモックアップを作る

UIが多い機能の場合、先にモックアップステップを追加してレビューする:

/ck:brainstorm/ck:plan/ck:frontend-design (mockup) → Review → /ck:cook

モックデータを使ったHTMLモックアップは実際の実装より速い。デザインの問題を早期に発見し、手戻りを防ぐ。

DO: 具体的なコンテキストを提供する

Bad
add tests for auth
Good
write tests for src/auth/token-refresh.ts: - successful refresh with valid token - failure when token expired > 7 days - concurrent refresh requests

DO: コンテキストを頻繁にクリアする

/clear が必要なタイミング:

Section 08

バッドプラクティス(避けること!)

キッチンシンクセッション
1つのセッションで無関係なタスクを多数こなす → コンテキストがノイズで溢れ、Claudeが混乱する。
"Fix login" → "Add dark mode" → "Optimize images" → "Back to login"

修正:無関係なタスクごとに /clear を使う

同じ問題を繰り返し修正する
Claudeが間違える → 修正する → また間違える → また修正... 失敗したアプローチでコンテキストが汚染される。

修正:2回修正に失敗したら → /clear してより良いプロンプトを書く

「簡単な」タスクの計画をスキップ
「これは簡単、計画不要」→ 3時間後、まだエッジケースをデバッグしている。

修正:軽量な計画には /ck:plan --fast を使う

検証なしに信頼する
Claude:「完了!」→ プロダクションにデプロイ → すべてが壊れる。

修正:/ck:test + 手動テスト + コードレビュー → その後デプロイ

漠然としたプロンプト
「よくしてください」「バグを直してください」「認証を追加してください」——Claudeが正しく実行するのに十分なコンテキストがない。

修正:具体的な症状 + 場所 + 期待される動作

Section 09

一般的なワークフローパターン

パターン1: 素早い修正(< 5分)
/ck:cook --fast Fix typo /ck:git cm "fix: typo"
パターン2: 標準的な機能
/ck:brainstorm /ck:plan → /ck:cook /ck:git cm
パターン3: 複雑(複数日)
Day 1: /ck:brainstorm → /ck:plan Day 2+: /ck:cook [Phase N] /clear between phases
パターン4: バグ調査
/ck:debug [symptom + logs] Phân tích root cause → fix thủ công hoặc /ck:fix
Section 10

一般的なワークフローパターン

Beginner 1週目
/ck:brainstorm /ck:plan /ck:cook /ck:fix /ck:ask /ck:test /ck:git
Intermediate 2〜4週目
/ck:scout /ck:code-review /ck:debug /ck:ship /ck:watzup /ck:frontend-design /ck:ui-styling
Advanced 2ヶ月目以降
/ck:team /ck:autoresearch /ck:predict /ck:security /ck:loop /ck:scenario /ck:xia /ck:bootstrap 70+の他のスキル

このチートシートは14の頻用コマンドのみを掲載。全コマンドの完全リファレンス、詳細構文、実例は vividkit.dev/guides/commands をご覧ください。

Section 11

チートシート

状況 コマンド
選択肢を探索/ck:brainstorm [question]
機能を計画/ck:plan [description]
機能を実装/ck:cook [description]
素早い小修正/ck:cook --fast [fix]
バグを修正/ck:fix [symptom]
技術的な質問/ck:ask [question]
テストを実行/ck:test [path]
コードベースを探索/ck:scout [path]
コードレビュー/ck:code-review [path|--pr N]
変更をレビュー/ck:watzup
コミット/ck:git cm "message"
フルリリースパイプライン/ck:ship
コンテキストをクリア/clear
初心者モードを設定/ck:coding-level 1
このチートシートは14の頻用コマンドのみを掲載。全コマンドの完全リファレンス、詳細構文、実例は vividkit.dev/guides/commands をご覧ください。
ホームに戻る