ck

ck skill の概要

ck ができること

ck は Claude Code 向けのプロジェクトメモリ skill で、現在のチャットの外側に再利用可能なコンテキストを保存します。複数のリポジトリをまたいで作業し、毎回同じ背景説明を書き直したくない人のために設計されています。やることはシンプルで、プロジェクトを一度登録したら、決定的な Node.js コマンドでコンテキストを保存・再開・確認・一覧表示・削除できます。

ck skill を入れるべき人

ck skill と最も相性がいいのは、Claude Code を使って継続的にリポジトリ作業をする開発者です。特に、プロジェクトの目標、制約、意思決定をセッションをまたいで残したい場合に向いています。また、ck for Context Engineering としても有用で、永続的なプロジェクトメモリと、その場しのぎのプロンプト履歴を分離できます。単発のプロンプトが中心であったり、Claude Code のローカル skill システムを使っていなかったりするなら、ck の価値は下がります。

通常のプロンプトと ck の違い

通常のプロンプトでも、リポジトリを一度要約することはできます。ck はそこに永続的な構造を加えます。たとえば、~/.claude/ck/projects.json のプロジェクト登録、プロジェクトごとの context.json という唯一の正本、生成される CONTEXT.md、そしてプロジェクトのコンテキストを自動読み込みできるセッション開始フックがあります。実務上の差は一貫性です。コマンドがローカルスクリプトを呼び出すため、アシスタントに曖昧に「これを覚えておいて」と頼むより、モデル依存が小さいワークフローになります。

ck skill の使い方

まず読むべきコンテキストとファイル

ck install では Claude Code の skills 機構を使い、そのあとまず skills/ck/SKILL.md を確認します。続いて、次のファイルを読みます。

• commands/init.mjs
• commands/save.mjs
• commands/resume.mjs
• commands/info.mjs
• hooks/session-start.mjs

この順序には意味があります。init.mjs では ck が現在のリポジトリから何を推定しようとするかが分かり、save.mjs では厳密な JSON スキーマが定義され、resume.mjs と info.mjs では日常利用で実際に返ってくる内容を確認できます。

実際の ck の呼び出し方

ck usage の基本はコマンドベースです。主なコマンドは次のとおりです。

• /ck:init で現在のプロジェクトを登録する
• /ck:save でセッション状態を保存する
• /ck:resume でフルブリーフィングを読み込む
• /ck:info で簡易スナップショットを確認する
• /ck:list で登録済みプロジェクトを一覧する
• /ck:forget でプロジェクトを削除する
• /ck:migrate で旧 v1 データを変換する

実装上の重要な点として、ck はアシスタントが ~/.claude/skills/ck/commands/ 配下の Node スクリプトを実行し、stdout を整形して提示することを前提にしています。init では即保存せず、まず検出したプロジェクト情報の下書きを作り、ユーザー確認後に確定 JSON を save.mjs --init に渡します。

より良い結果を出す入力の与え方

ck は、自動検出では拾いきれない不足情報を補うときに最もよく機能します。/ck:init に向く入力は次のとおりです。

• 明確なプロジェクト名
• 1文の説明
• 主要スタック
• 現在のゴール
• 明示的な制約や「やらないこと」
• 可能ならリポジトリ URL

/ck:save では、次のようなセッション入力が強いです。

• summary: 今回何が変わったか
• leftOff: どこで止めたかを正確に
• nextSteps: 具体的な次の一手を 2〜5 件
• decisions: 何を決めたか、その理由
• blockers: 未解決の問題

弱い入力: 「認証周りを進めた」
強い入力: 「refresh token rotation を実装した。apps/api/tests/auth.spec.ts の integration tests が失敗しているところで止まっている。次は cookie domain の扱いを直す。モバイルクライアントがまだ対応できていないため、server-side revocation は当面維持する判断にした。」

実プロジェクトでのおすすめワークフロー

実践的な ck guide は次の流れです。

1. リポジトリのルートで /ck:init を実行する。
2. 検出された下書きを確認し、必要なら修正してから確定する。
3. まとまった作業の終わりに /ck:save を実行する。
4. 次のセッションでは、フルコンテキストが必要なら /ck:resume、軽く確認したいだけなら /ck:info を使う。
5. 複数プロジェクトを切り替えるときは /ck:list を使う。

ck for Context Engineering として採用するなら、これを永続的なプロジェクトブリーフィング層として扱ってください。短命なブレストはチャットに残しつつ、安定した事実、決定事項、次の一手は ck に移しておくと、次回のセッションをよりきれいな状態から始められます。

ck skill よくある質問

ck は初心者向けですか？

はい、ただし Claude Code とローカルコマンド実行に慣れていることが前提です。考え方自体は分かりやすい一方で、この skill は会話型というより運用寄りです。初心者は、確認ステップ、JSON の受け渡し、データの保存場所を理解するために SKILL.md を丁寧に読む必要があるかもしれません。

ck は通常のプロンプトよりいつ有利ですか？

同じプロジェクトが数日から数週間にわたって繰り返し出てくるときに ck は有利です。単に賢いプロンプトテンプレートではなく、構造化されたプロジェクトメモリをディスク上に保持し、一貫して読み込み直せます。作業が一時的、あるいは 1 セッション限りなら、通常のプロンプトのほうが十分で、しかも速いことが多いです。

主な制約やリスクは何ですか？

最大の制約は、ck の精度が保存された内容に強く依存することです。/ck:save を飛ばすと、メモリ層はすぐ古くなります。もう一つの制約は適合範囲で、これは Claude Code のローカル skills と ~/.claude/ck/ のようなファイルシステム規約を前提にしています。汎用のクラウドメモリサービスではありません。また、CONTEXT.md は生成物なので、そこを手で編集して真実を保つのは誤った運用です。

ck skill の改善方法

ck に渡すプロジェクト登録入力を良くする

ck を最も効果的に改善する方法は、初期登録の品質を上げることです。package.json、README の内容、git メタデータからの自動検出は役立ちますが、しばしば不十分です。/ck:init の時点で下書きを積極的に修正してください。ゴールを具体化し、制約を明示すると、後で /ck:resume の出力が、単なるスタック名だけの場合よりずっと実用的になります。

よくある失敗パターンを避ける

ck の典型的な問題は予測しやすいです。

• 間違ったディレクトリで登録する
• あいまいな要約を保存する
• 次の作業を更新し忘れる
• 生成された markdown を正本だと思い込む
• プロジェクトの識別を確認せずにコンテキストを削除する

出力が弱く感じるときは、基礎となる context.json に十分な情報が本当に入っているかを確認してください。品質の問題の多くは、コマンドスクリプト自体ではなく、保存された状態の情報不足から来ます。

最初の出力のあとに改善を重ねる

ck usage を良くするには、最初に保存したコンテキストを完成版だとみなさないことです。/ck:resume のあとに、「明日、チャット履歴がゼロでも必要になる情報は何か」を自問してください。そして、より明確な決定事項、ブロッカー、停止地点を追加して、もう一度保存します。優れた ck skill の運用は、長い日記ではなく、短くて価値の高いブリーフィングへと育っていきます。