Menú
moka-1 プロジェクトの Architecture Decision Record を docs/adr/ に日本語で書く。実装完了後やユーザーが「ADR書いて」「ADRにまとめて」「決定を記録して」と言った時、または設計上の決定(モデル選定・ライブラリ採否・構成変更)を下した直後に使用する。テンプレート(docs/adr/template.md)参照方式・ADR00001.md からの連番。デプロイ工程は含まない。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Rust ベストプラクティス(Plecto WASM フィルタ向け、Edition 2024)。plecto:filter WIT コントラクトを実装する WASM Component Model フィルタの規約とツールチェーン。
Grilling session that challenges your plan against moka-1's documented design decisions (tenets, ADRs) and domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when the user wants to stress-test a plan against the project's language and documented decisions, or says 「設計を詰めて」「用語を固めて」「ドキュメントと突き合わせて」.
クリーンアーキテクチャの依存ルールを moka-1 のミニマリズム制約下で適用する指針。レイヤ分割・interface 設計・依存方向の判断基準と、過剰抽象化を避けるガードレールを提供する。
Web調査の方法論。一次ソース(RFC・公式仕様・公式ドキュメント・原論文・ソースコード)を最優先し、検索クエリの多角化・横断的検証(lateral reading)・独立ソースでの三角測量を経て、出典付きで報告する手順。
moka-1 スタックの Docker Compose 操作と compose.yaml の書き方。ワンキック起動・開発ループ・ヘルスチェック・開発機(iGPU/Vulkan)固有設定・トラブルシュート。
Go ベストプラクティス(moka-core 向け、Go 1.26+)。常駐エージェントループ・LLM クライアント・フィード取得を含む moka-core の実装規約。
| name | moka-adr-writer |
| description | moka-1 プロジェクトの Architecture Decision Record を docs/adr/ に日本語で書く。実装完了後やユーザーが「ADR書いて」「ADRにまとめて」「決定を記録して」と言った時、または設計上の決定(モデル選定・ライブラリ採否・構成変更)を下した直後に使用する。テンプレート(docs/adr/template.md)参照方式・ADR00001.md からの連番。デプロイ工程は含まない。 |
| allowed-tools | Bash, Read, Glob, Grep, Edit, Write |
2 フェーズ: 実装確認(§1)→ ADR 執筆(§2)。Alt の ADR 運用に忠実だが、デプロイ工程(Pact/c2quay)は moka-1 に存在しないため無い。 設計判断のみの ADR(コード変更なし)は §1 をスキップする。
ADR は「動いた状態」を固定する行為なので、コード変更を伴う場合は最低限のテストを先に回す:
| 変更の種類 | コマンド |
|---|---|
| moka-core (Go) | cd core && go test ./... |
| Plecto フィルタ (Rust) | cd plecto/filters && cargo test |
| moka-web (Svelte/TS) | cd web && bun run check && bun test |
| eval/ (Python) | cd eval && uv run pyrefly check . && uv run pytest |
| ドキュメントのみ | skip |
テストが落ちていたら ADR は書かず、原因を報告して止まる。ADR は「動いた実装の決定記録」であり、憶測を書く場所ではない。
ls docs/adr/ | grep -E '^ADR[0-9]{5}\.md$' | sort | tail -1 # 最新番号を確認
ADR + 5 桁ゼロ埋め: ADR00001.md, ADR00002.md, ...(最新 +1。1 本も無ければ ADR00001.md から)docs/adr/template.md を Read で開き、そのセクション見出しをそのまま使う(勝手に増減しない)| フィールド | 値の決め方 |
|---|---|
title | 動詞始まりの行動指向の一文。ADR 番号は含めない |
date | YYYY-MM-DD(当日) |
status | 原則 accepted。過去 ADR を無効化する場合のみ新 ADR 側は accepted のまま、旧 ADR を superseded by [[ADRNNNNN]] に更新 |
tags | §2.4 の許可タグから最大 5 個 |
affected_modules | モジュール名と変更概要を 1 行/件(core/internal/llm, plecto/filters/auth, web, eval, compose など) |
aliases | ADR-N と ADR-0000N の 2 形式を必ず両方(Obsidian リンク解決用) |
[[ADRNNNNN]] タイトル 形式(Obsidian のグラフビュー / バックリンク用)。draft への参照は相対リンクで可architecture, minimalism, agent, rss, feed, llm, model-selection, prompt,
rag, embedding, highlight, recap, database, migration, frontend, backend,
api, docker, compose, plecto, wasm, filter, edge, security, authentication,
rate-limiting, performance, testing, ci, refactoring, bugfix, logging,
eval, dogfooding, aix-hardware
この外のタグを増やしたくなったら、ADR を書く前にこのスキル(§2.4)を先に更新する。
含めない:
OK: localhost:XXXX、compose サービス名、ハードウェアスペック(HX370 / 64GB / iGPU 32GB — 性能判断の根拠として必要)。
Write ツールで docs/adr/ADRNNNNN.md を作る。heredoc や cat > ... は使わない。
書き込み後に Read で自分の出力を読み返し、見出し / frontmatter / wikilink 形式 / aliases の 2 形式を確認する。
旧 ADR を supersede した場合は旧ファイルの status 更新も忘れない。
docs/adr/ADRNNNNN.md)とタイトルdocs/adr/template.md — セクションと frontmatter のソース(真実はこちら)docs/tenets/moka-tenets.md §7 — 決定事項の公開まとめ(ローカルドラフト内のミニ ADR は番号体系の外)