القائمة
moka-1 プロジェクトの Architecture Decision Record を docs/adr/ に日本語で書く。実装完了後やユーザーが「ADR書いて」「ADRにまとめて」「決定を記録して」と言った時、または設計上の決定(モデル選定・ライブラリ採否・構成変更)を下した直後に使用する。テンプレート(docs/adr/template.md)参照方式・ADR00001.md からの連番。デプロイ工程は含まない。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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 は番号体系の外)