loopkit は、Claude Code・Cursor・Codexを横断して同じスキルを使い回せる、最小の後付けハーネスです。Claude Code、Cursor、Codex、Gemini CLI、Windsurf、GitHub Copilot CLI——2026年、AIコーディングエージェントは一気に乱立しました。多くの開発者が、用途やコストに応じて複数のツールを併用しています。ここで地味に効いてくるのが「ツールを乗り換えるたびに、同じ知識を毎回イチから教え直している」という無駄です。コーディング規約、検証の作法、「作った本人にチェックさせない」という規律——こうしたプロジェクト知識やエージェント運用の型は、本来ツールに依存しないはずなのに、各ツールの設定形式に縛られてバラバラに散らばってしまいます。
この問題に、「一箇所に書いて、どのツールにも持ち込む」という素朴な解で応えるのが、本記事で解説する Archive228/loopkit です。loopkitは、既存プロジェクトに1コマンドで後付けできる最小の .claude/ ハーネスと、49個の実戦スキルをまとめたMITライセンスのリポジトリ。作者いわく「方法論でもライフサイクルでもフレームワークでもない、自分が実際に手に取る道具箱（loadout）そのもの」です。★588・fork 109（2026年7月時点）と、静かに支持を集めています。
.claude/ハーネス・skills/・run.shがディスク上のファイルとして並ぶ。About欄は★588・MIT・クロスツール対応を示す（出典: Archive228/loopkit）本記事では、この「横断ハーネス」というアイデアがなぜ効くのか、そのアーキテクチャ（1枚のスキルが複数エージェントに届く仕組み）、Plan→Act→Verifyループとverifierサブエージェントの実体、49スキルの実務カテゴリ別の要点、そしてClaude Code / Cursor / Codex それぞれの設定例までを、公式リポジトリの一次情報にもとづいて整理します。
1. loopkitとは何か——「最小ハーネス＋49スキル」の全体像
loopkitが読者の抱える3つの疑問——①結局何ができるのか／②何を解決するのか／③何を代替するのか——に、まず端的に答えておきます。①できることは、任意のコーディングエージェントに「Plan→Act→Verify」という3段の規律と、状況に応じて自動で読み込まれる49の専門スキルを後付けすること。②解決することは、長時間動くエージェントが必ずハマる2つの失敗モード——「一度にやりすぎる（doing too much at once）」と「早すぎる勝利宣言（premature victory）」——を、スキルではなく構造（ハーネス）で防ぐこと。③代替するものは、各ツールにバラバラに散らばった自作ルール群と、重厚な方法論フレームワークです。
READMEはloopkitの正体を、こう言い切ります。
A drop-in
.claude/harness + 49 battle-tested skills for coding agents.（コーディングエージェント向けの、後付けできる.claude/ハーネス＋49の実戦スキル）
ポイントは「ランタイムがない」ことです。loopkitはデーモンでもサーバでもラッパーCLIでもありません。中身はディスク上のファイル——設定、フック、verifierサブエージェント、そして8行のループランナーだけ。だからこそ、どんなプロジェクトにも軽く乗り、気に入らなければ消せます。
インストールされるファイル構成を見ると、その「最小さ」がよく分かります。
your-project/
├── .claude/
│ ├── CLAUDE.md # 60行の常駐コンテキスト（自分のスタックに合わせて編集）
│ ├── settings.json # 権限のallowlist＋書き込み時フォーマットfック
│ ├── agents/
│ │ └── verifier.md # 敵対的verifierサブエージェント（Haiku・JSON出力）
│ ├── hooks/ # セッション開始時のブートストラップ
│ └── skills/ # 49スキル（symlinkまたはコピー）
├── .mcp.json # MCPサーバ配線（github・context7）
├── MEMORY.md # セッション横断メモリの索引
└── run.sh # Plan→Act→Verifyループランナー
導入は3通り。Node不要のcurl経由が推奨です。
# curl経由（Node不要・推奨）
curl -fsSL https://raw.githubusercontent.com/Archive228/loopkit/main/install.sh | bash
# skills.sh経由（SKILL.mdを読むエージェントなら何でも）
npx skills add Archive228/loopkit
# git経由（forkしたい人向け）
git clone https://github.com/Archive228/loopkit
cp -r loopkit/.claude your-project/
curlインストーラは既定で既存ファイルを上書きしません（スキップ）。上書きは FORCE=1、現行 .claude/ のバックアップを取ってから書くなら BACKUP=1、インストール先の変更は DEST=/path で指定します。書き込んだファイルは逐一表示され、最後に claude CLI がPATH上にあるかを検証し、致命的な失敗があれば非ゼロで終了します。この「安全側に倒す」挙動が、既存プロジェクトへの後付けを現実的にしています。
多くのエージェント向けキットが「機能を足す」方向で膨らむのに対し、loopkitは「新しい方法論を覚えさせない・ランタイムを持たない・ロックインしない」という引き算で設計されています。run.shはたった8行。floor（最低限の床）だけ敷いて、あとは開発者のワークフローに手を出さない——この禁欲さが、ツールを横断して使い回すうえで効いてきます。
2. なぜ「横断ハーネス」が効くのか——ツール乱立時代の実課題
そもそも、なぜ「複数のコーディングツールで同じスキルを使い回す」ことに価値があるのでしょうか。ここが本記事の切り口です。
2026年の現実として、開発者は1つのツールに一本化していません。難しい設計判断はClaude Codeで、エディタ内の素早い補完はCursorで、CLIでの自律的な反復はCodexやGemini CLIで——というように、タスクとコストに応じてツールを切り替えるのが当たり前になりました。ところが、ツールごとに設定の置き場所も書式もバラバラです。Claude Codeは .claude/、CursorはルールやAGENTS.md、CodexはAGENTS.md……と、同じ「プロジェクトの作法」を何度も別々の場所に書く羽目になります。
さらに厄介なのは、AIコーディングエージェント特有の失敗がどのツールでも同じように起きることです。loopkitのREADMEは、長時間動くエージェントが実際にハマる失敗を2つに絞り込みます。
・一度にやりすぎる（doing too much at once）：1セッションに複数の機能を詰め込み、すべてを中途半端なまま出荷してしまう
・早すぎる勝利宣言（premature victory）：本当は壊れているのに「done」と宣言してコミットしてしまう
READMEはこの2つを「スキルの形をした問題ではなく、構造の問題（structural, not skill-shaped）」だと喝破します。つまり、いくら賢いスキルを足しても直らない。必要なのは、1セッション1機能に縛る run.sh と、作った本人とは別の目で検証する verifierサブエージェントという「構造的な答え」だ、と。
この「構造」と「スキル」は、ツールに依存しません。だからこそ、それらをtool-agnosticなマークダウンとして一箇所に書き、どのエージェントにも持ち込めることに価値が生まれます。loopkitの狙いを一文で言えば、「方法論を押し付けずに、どのツールにも同じ最低限の規律とスキルを敷く」。乱立時代における、地に足のついた解です。
3. アーキテクチャ——1枚のスキルが複数エージェントに届く仕組み
では、具体的にどうやって「1つの定義」を複数のエージェントに届けているのでしょうか。ここがloopkitの設計の肝です。答えは、リポジトリ直下の AGENTS.md を単一の真実（single source of truth）にし、各ツールはそれを自分の書式で取り込む——という、いわば「アダプタ」構造です。
AGENTS.md は、Claude Code・Cursor・Codex CLI・Gemini CLI・Ampが共通で読む「ループ契約」です。そこには「Plan→Act→Verify」「1セッション1機能」「終了時のクリーンステート契約」といった、ツールに依存しない規律が書かれています。そしてClaude Code向けの .claude/CLAUDE.md は、先頭でこの契約を @../AGENTS.md として取り込む（import）だけ。同じ契約を二重に書かず、Claude固有の追記（スラッシュコマンドやhookの説明）だけをCLAUDE.md側に足します。
この「共有契約＋各ツールのアダプタ」構造を図にすると、こうなります。
ループ契約：Plan→Act→Verify / 1機能 / クリーンステート"] S["skills/*/SKILL.md
49スキル（YAMLヘッダ＋短い本文）"] end A -->|"@../AGENTS.md で取り込む"| CC["Claude Code
.claude/CLAUDE.md＋.claude/skills/＋ハーネス"] A -->|"ネイティブに読む"| CU["Cursor
AGENTS.md＋スキル参照"] A -->|"ネイティブに読む"| CX["Codex CLI
AGENTS.md＋スキル参照"] A -->|"ネイティブに読む"| GM["Gemini CLI / Amp
AGENTS.md＋スキル参照"] S -.->|"symlink / コピー / npx skills add"| CC S -.-> CU S -.-> CX S -.-> GM
図の下半分にあるとおり、スキル本体（skills/*/SKILL.md）は、Claude Codeには .claude/skills/ へsymlinkまたはコピーされ、他ツールには npx skills add などで配られます。どのツールも「SKILL.mdを読み、descriptionのトリガー語句に一致したら本文を読む」という同じ動作をするので、まったく同じスキルファイルが全ツールで機能するわけです。
同梱ハーネス（settings.json・hooks・verifier.md）は、正直に言えば Claude Codeの形をしています。READMEもそこは率直で、「Cursor/Codex/Geminiユーザーはハーネスを無視してスキルだけ使うか、3つのハーネスファイルを移植すればいい（どれも小さい）」と案内しています。つまりloopkitは、「スキルとAGENTS.md契約は完全に横断・ハーネスはClaude Code最適＝移植可能」という、現実的な二層構造になっているのです。
loopkitのAGENTS.mdは末尾で「When user instructions and this file disagree, user instructions win.（ユーザー指示とこのファイルが食い違ったら、ユーザー指示が勝つ）」と宣言しています。契約はあくまで既定値であり、開発者の指示を縛るものではない——この一文が、方法論を押し付けないloopkitの思想を象徴しています。
4. Plan→Act→Verifyループとverifierサブエージェント
loopkitの「構造的な答え」の中身を、実ファイルで見ていきましょう。すべてのスキルは、次の3段のループの中で発火します。
PLAN ──▶ ACT ──▶ VERIFY
▲ │
└────── revise ──────┘
・PLAN：spec-first・context-budget・tool-restraint・planner-spec-expand・sprint-contract がここで読み込まれる
・ACT：ドメインスキル（debug・security・testing・refactor・docs・data・git/ops）がここで読み込まれる
・VERIFY：adversarial-verify と evaluator-calibration、そしてverifierサブエージェントがループを閉じる
このループを無人で回すのが run.sh です。中身は驚くほど短く、8行のシェルスクリプトにすべてが詰まっています。
#!/usr/bin/env bash
# loopkit loop runner: fresh context each turn, state on disk
set -euo pipefail
while true; do
claude -p "Read PROMPT.md and IMPLEMENTATION_PLAN.md. Do the next step. Commit on green."
claude -p "/verify" || echo "verify failed, will retry"
grep -q "^STATUS: done$" IMPLEMENTATION_PLAN.md && { echo "done"; break; }
sleep 5
done
注目すべきは「fresh context each turn, state on disk（毎ターン新鮮なコンテキスト・状態はディスク上）」というコメントです。会話履歴に状態を溜め込まず、PROMPT.md（ゴール）と IMPLEMENTATION_PLAN.md（進捗）というファイルに状態を外出しする。だからコンテキストが膨れず、何セッションでも一貫して同じゴールを追えます。そして各ターンの後に必ず /verify を挟み、IMPLEMENTATION_PLAN.md に STATUS: done が書かれるまでループを回し続けます。
このループの「載っている（load-bearing）」部分が、verifierサブエージェントです。定義はわずか10行ですが、思想が凝縮されています。
---
name: verifier
description: Reviews a diff against the goal spec assuming the code is broken. Invoke after every code change.
model: haiku
tools: [Read, Grep, Bash]
---
You are a verifier. Read the goal spec (PROMPT.md). Read the diff. Assume it is broken.
Check the 11 "fake done" shortcuts (see skills/adversarial-verify). Return JSON:
`{"passes": bool, "failures": [{"line": int, "shortcut": str, "why": str}]}`.
Do not propose fixes. Do not run code. Do not be polite.
この設計の狙いは明確です。「作った本人の頭でレビューさせない」。実装したエージェントは、自分のコードに甘くなります（これをloopkitは self-eval-bias というスキルで別途扱っています）。だから、diffを「壊れている前提」で読む敵対的な別エージェントを、しかも軽量なHaikuで走らせ、adversarial-verify が定義する「11個の『fake done（偽の完了）』ショートカット」をチェックさせる。修正案は出さない・コードは実行しない・お世辞も言わない——判定だけをJSONで返す割り切りが、verifierを信頼できる関門にしています。
settings.json も、この規律を機械的に支えます。allowlistは読み取り系のBash（ls・git status・git diff・cat・grep）と Read に限定し、denyリストで rm -rf と git push --force を封じます。さらに PostToolUse フックが、Edit/Writeのたびに prettier --write を走らせ、diffが常にレビュー可能な状態に保たれます。安全な操作は自動で許し、危険な操作は構造的に禁じる——ここにも「floorだけ敷く」思想が一貫しています。
スキル本体を短く保つため、長い参照はオンデマンドで読み込まれるチェックリストに切り出されています。docs/checklists/ には3枚——「何をもって『出荷済み』とするか」を定義する Definition of Done、verifierが探す15のパターンをまとめた Red Flags、そして「テストは後で書きます」のような言い訳とその反論を並べた Rationalizations が置かれ、スキルは必要なときだけそこを指し示します。「スキルは1ページに収め、200行必要なら docs/checklists/ に移す」——この線引きが、大量スキルを軽く保つ工夫です。
もう一つ、ループの信頼性を支えるのが AGENTS.md のクリーンステート契約（clean-state contract）です。すべてのセッションは、終了時に「全コードをgitへコミット済み・作業ツリーに未コミットの変更なし・IMPLEMENTATION_PLAN.md に『やったこと／次にやること／既知の課題』を更新済み・devサーバ停止済み」という状態を満たすことを求められます。そして「1セッション1機能（single-feature rule）」。READMEもAGENTS.mdも「複数機能を詰めたセッションは、すべてを中途半端に出荷する——これは実測済みだ」と断言し、次の機能は次のセッションに回す規律を徹底します。「速く終わらせる報酬はない。中途半端に放置する実コストがある」という一文が、この契約の背骨です。
5. loopkitの49スキルを実務カテゴリ別に——実戦で効くTOP15
loopkitの49スキルは、10のトラック（実務カテゴリ）に分かれています。すべてを網羅すると冗長なので、実際の開発で効く15個を、カテゴリ別に絞って紹介します。各スキルは「name → 何をするか → いつ発火するか」の3点で定義されている点に注目してください。トリガー（description）が一致したときだけ本文が読み込まれるので、49個あっても常時のコンテキスト負荷はほぼゼロです。
| トラック | スキル | 何をするか（いつ発火するか） |
|---|---|---|
| loop & harness | planner-spec-expand |
1〜4文の要件を、設計言語と順序付き機能リストを持つ本格的な仕様へ拡張（新規プロジェクト・大型機能の起点） |
| loop & harness | sprint-contract |
「done」をコード前にスクリプトで判定可能な述語として交渉（evaluatorを絡めた実装スプリント時） |
| loop & harness | progress-reading-protocol |
セッション開始時の固定6手順（pwd→進捗→git log→機能数→init→スモークテスト） |
| loop & harness | harness-stripping |
新モデルが出るたび、ハーネス部品を1つずつ外して効果を測る（過剰な足場を積む前に） |
| agent/llm | context-budget |
大きな読み込み前に作業セットを削る（長セッション・大規模リポ） |
| agent/llm | tool-restraint |
最小のツールを選ぶ（何でもBashで済ませる悪癖の防止） |
| agent/llm | subagent-fanout |
独立した調査を並列化（リサーチ・監査タスク） |
| debug | systematic-debugging |
仮説→検証→絞り込み（一発で直せないバグ） |
| debug | read-the-trace |
ノイズから本当の失敗を抽出（スタックトレース・CIログ） |
| testing | write-failing-test-first |
greenの前にredを書く（挙動変更・バグ修正） |
| testing | flaky-hunter |
断続的な失敗を再現・隔離・隔離（不安定なCI） |
| security | secret-scan |
コミット前に鍵を検出（pre-push・PRレビュー） |
| security | owasp-review |
diffにOWASPトップ10のパス（ユーザー向け変更のマージ前） |
| review | adversarial-verify |
エージェントが「done」を偽装する11のショートカットを列挙（タスク完了フリップ前） |
| review | verification-before-completion |
正確なコマンドを実行し、出力を読み、それから主張する（あらゆる「done」宣言前） |
とくにloopkitらしいのが、新設された loop & harness トラックです。ここには「エージェントを長時間・複数セッション・複数エージェントで動かす規律」が集められています。たとえば sprint-contract は、「done」を曖昧な言葉ではなく「このスクリプトが0で終わること」のような機械判定可能な述語として最初に握る、というスキル。harness-stripping は、新モデルが出るたびに「その足場、本当にまだ要る？」と問い、部品を1つずつ外して効果を測る——足場を積む前に引き算するという、loopkit全体の思想がそのままスキルになったものです。
もう一つの白眉が adversarial-verify の「11の偽装ショートカット」です。エージェントが完了を偽るときの典型パターン——テストを消してredをgreenにする、happy pathしか通さない、出力を読まずに「通った」と言う——を明示的にリスト化し、verifierがそれを一つずつ潰します。これは公式比較ドキュメントでも「loopkit独自」と評される、他パックにない強みです。
49スキルと聞くと重そうですが、実際は逆です。各スキルのdescriptionがトリガーとして働き、タスクに一致したものだけが本文まで読み込まれます。だから常時のコンテキスト消費は最小。「たくさん積んでも、必要なときだけ効く」——このトリガー機構が、大量スキルとの共存を可能にしています。
6. Claude Code / Cursor / Codex それぞれの設定例
ここからは実践編です。loopkitを各ツールでどう使うか、設定例を具体的に示します。中核は「AGENTS.mdを1枚置く」ことで、あとは各ツールがそれをどう読むかの違いです。
Claude Codeでの設定
Claude Codeが最も「フルスペック」で使えます。curlインストーラを流すだけで、.claude/ 一式（CLAUDE.md・settings.json・agents/verifier.md・hooks・skills）とAGENTS.mdが入ります。
cd your-project
curl -fsSL https://raw.githubusercontent.com/Archive228/loopkit/main/install.sh | bash
claude # 同じディレクトリで起動
.claude/CLAUDE.md は先頭でAGENTS.mdを取り込み、Claude固有の入口を案内します。
@../AGENTS.md
# Project: <name>
Stack: <language, framework, db>.
## Claude-specific
- スラッシュコマンドは .claude/commands/ に。/spec・/verify・/loop が主な入口
- verifierサブエージェント（.claude/agents/verifier.md）は /verify から起動、evalグレーダーとしても再利用可
- SessionStartフック（.claude/hooks/session-start）が using-loopkit スキルを起動時に注入
SessionStartフックが using-loopkit（スキルのルーティング表）をターン1から注入するので、スキルの振り分けが最初から効きます。/spec で PROMPT.md を書き、/verify で敵対的検証、/loop でPlan→Act→Verifyを回す——という流れです。
Cursorでの設定
Cursorは、ハーネス（settings.json等）は無視し、スキルとAGENTS.md契約だけを使うのが現実的です。CursorはルートのAGENTS.mdを読めるため、まずそれを置き、スキルをプロジェクトに配ります。
# ハーネスは使わず、スキルとAGENTS.mdだけ入れる
npx skills add Archive228/loopkit
# → skills/ と AGENTS.md がプロジェクトに入る
あとはCursorのルール（Project Rules）から、AGENTS.md と skills/ を参照するよう促します。Cursorの補完・チャットに「Plan→Act→Verifyの契約」と「必要時に読むスキル群」を持ち込めます。settings.jsonのフックやverifierサブエージェントはClaude Code固有なので、Cursorで敵対的検証をやりたい場合は、skills/adversarial-verify の11ショートカットをチェックリストとして手動運用するか、Cursor側のレビュー機能に翻訳して移植します。
Codex CLI / Gemini CLIでの設定
CodexとGemini CLIは、AGENTS.md をネイティブに読むのが最大の利点です。ルートにAGENTS.mdがあれば、それがそのままセッション契約になります。
git clone https://github.com/Archive228/loopkit
cp loopkit/AGENTS.md your-project/AGENTS.md # 契約を置く
cp -r loopkit/skills your-project/skills # スキルを置く
cd your-project && codex # または gemini
AGENTS.mdの「1セッション1機能」「クリーンステート契約」「/verify を通すまでコミットしない」といった規律が、そのままCodex/Geminiのセッションに効きます。スキルは各ツールがSKILL.mdを読める限り機能します。ハーネス3ファイル（settings/hooks/verifier）を移植したい場合も、READMEが言うとおり「どれも小さい」ので、各ツールのフック機構やサブエージェント機構に翻訳する作業は軽量です。
7. superpowers / mattpocock / osmani との違い——横断・軽量の立ち位置
スキルパックはloopkitだけではありません。loopkit自身が同梱する公式比較ドキュメント（docs/vs-others.md）は、他パックの強みを正直に認めた上で、自分の立ち位置を示しています。「相手を貶すためではなく、あなたのループに合う道具を選ぶために使え」という前置きが誠実です。
| 観点 | loopkit | obra/superpowers | mattpocock/skills | addyosmani/agent-skills |
|---|---|---|---|---|
| ハーネス同梱（settings・verifier・ループランナー） | あり | 部分的 | なし | なし |
| スキルはトリガーで読み込み | あり | あり | あり | あり |
| 方法論の強制 | なし | Prime Radiant | GSD寄り | 6フェーズライフサイクル |
| スラッシュコマンド | なし | 一部 | 多い | 8つのライフサイクルコマンド |
| 非Claudeエージェント対応 | あり | Claude優先 | マルチ | マルチ |
| インストールサイズ | 極小 | 中 | 中 | 中 |
loopkitの独自性は3点に集約されます。第一に、ハーネス（settings.json＋verifierサブエージェント＋ループランナー）をインストールに含める唯一のパックであること。他はすべて「あなたはもう動く .claude/ を持っている前提」で、スキルだけを配ります。第二に、方法論税がゼロであること。superpowersはPrime Radiant（spec-first/TDDを端から端まで）に深くコミットし、osmaniは /spec→/plan→/build→/test→/review→/ship の6フェーズを敷きます。loopkitはそのどれも強制しません。第三に、adversarial-verify の11ショートカットという、完了偽装を名指しで潰す独自スキルを持つこと。
もちろん弱点も正直に書かれています。loopkitにはスラッシュコマンドのUXがなく（/build auto のような操作感が欲しければosmaniが上）、単独メンテナのため継続性を重視するならAnthropic公式スキルの方が安全、と。superpowersは「Prime Radiantごと採用する覚悟」が要り、mattpocockは「Mattの好み（triage状態機械・PRD合成）を買えるか」に依存し、osmaniは「6フェーズの儀式が小さな変更には重い」。どれが優れているかではなく、あなたのループに合うのはどれか、という選び方をloopkit自身が推奨しています。
そして重要なのが、これらは排他ではないという点です。スキルはただのマークダウンなので、混ぜて使えます。
npx skills add Archive228/loopkit # ベース＋ハーネス
npx skills add mattpocock/skills/grilling # Mattのインタビュー型ループ
npx skills add addyosmani/agent-skills/checklists # 参照レイヤ
トリガー機構のおかげで、追加スキルを読み込むコストはほぼゼロ（frontmatterが一致したときだけ発火）。混ぜて使うのが想定された使い方だと公式が明言しています。loopkitは「土台（floor＋ハーネス）」を提供し、その上に他パックの強みを重ねられる——このコンポーザブルな立ち位置こそ、横断・軽量を掲げるloopkitの真骨頂です。
まとめ——「floorだけ敷く」という現実解
loopkitが示すのは、AIコーディングツールが乱立した2026年における、地に足のついた運用哲学です。重厚な方法論でエージェントの振る舞いを丸ごと支配するのでもなく、各ツールに自作ルールを散らかすのでもなく、「ツールに依存しないスキルと契約を一箇所に書き、どのエージェントにも同じ最低限の規律（floor）を敷く」。
・横断：AGENTS.mdという単一契約と、tool-agnosticなSKILL.mdで、Claude Code・Cursor・Codex・Gemini CLIに同じ作法を持ち込む
・構造：run.sh（1セッション1機能）と敵対的verifier（完了偽装を潰す）で、長時間エージェントの2大失敗をスキルではなく構造で防ぐ
・軽量：ランタイムなし・8行のループランナー・MIT。気に入らなければ消せるし、他パックと混ぜられる
「新しい方法論を覚えたくないが、エージェント運用に最低限の規律とスキルは欲しい」——そんな開発者にとって、loopkitは有力な選択肢です。まずは自分のプロジェクトにcurlで後付けし、AGENTS.md を1枚眺めるところから始めるのがよいでしょう。数値や挙動は変わり得るため、最新の正確な情報は必ず公式リポジトリで確認してください。
参照ソース
・Archive228/loopkit（公式リポジトリ） — README・skills/・.claude/ハーネス一式
・loopkit vs other skill packs（公式比較ドキュメント） — 他スキルパックとの正直な比較
・Loop and Harness engineering: 7 files, 5 steps（同梱の理論ドキュメント） — ハーネス設計の背景理論
