docs-kit ガイド

AI コーディングのための設計書管理ツール。

設計書は Markdown + YAML front matter のまま置いておく。そこに commit SHA ベースの鮮度検証を足すことで、「AI が古い設計書を疑わずに信じて、実装をそちらへ寄せてしまう」事故を防ぐ。Go 製の単一バイナリで、外部ランタイムは要らない。

status: v1.1.0 core + CLI と stdio MCP サーバの両方が揃っている。v1.1.0 で front matter のスキーマを出力する schema コマンドを追加した。

30 秒でわかる docs-kit

設計書の先頭に、「この文書が責任を持つコード範囲」と「最後に実装と突き合わせたコミット」を書く。

---
id: SPEC-editing-model
title: 編集モデル
status: current
scope: [src/core/editing/**]                          # この文書が責任を持つコード範囲
verified_at: 8f3a1c2e0b7d4a91c3f6e2d8b5a704c1e9f3d602 # 最後に実装と突き合わせた commit
---

あとは git 履歴が判定してくれる。

docs-kit stale

SPEC-editing-model  stale    code-changed: 3 files changed since 8f3a1c2
  - src/core/editing/model.ts (2 commits)
  - src/core/editing/undo.ts
ARCH-overview       ok       (verified at 8f3a1c2)

ok 1 / stale 1 / broken 0 / skipped 0

verified_at 以降に scope の中のコードが変わっていれば stale。CI が落ち、AI には「この文書は古い。コードを正としろ」と伝わる。

このガイドの読み方

ページ	内容	こんなときに
コンセプトと設計思想	何を問題と捉え、なぜこの解き方にしたのか。作らないと決めたもの	導入を検討している / 設計の意図を知りたい
ドキュメント管理ワークフロー	4 層構造・front matter・鮮度判定・日々の運用・AI 連携・CI	使い方の全体像を押さえたい。このガイドの本体
インストール	バイナリ / `go install` / CI / Claude Code への MCP 登録	まず動かしたい
プロジェクト初期設定	新規リポジトリに導入して最初の 1 本を書き切るまで	ゼロから始める
既存プロジェクトへの導入	既にある Markdown を段階的に管理下へ移す	設計書が既にある

はじめてなら インストール → プロジェクト初期設定 → ワークフロー の順。既存の設計書がたくさんあるなら コンセプト → 既存プロジェクトへの導入 から。

動作要件


OS	macOS / Linux / Windows (amd64, arm64。Windows arm64 は配布対象外)
必須	`git` (read-only でシェルアウトする)
ランタイム	不要 (単一バイナリ)
AI 連携 (任意)	MCP 対応クライアント (Claude Code 等)

docs-kit ガイド

30 秒でわかる docs-kit

このガイドの読み方

動作要件

関連