Communityライティング&編集github.com

ahmadrosid/nakama

GitHubのPR説明を、ADHDフレンドリーなスキャン可能フォーマットで作成または書き換えます。アウトカムファーストのリード、2行のBefore/After、短いWhy-safeリスト、1行の残余リスク、タイトなテスト計画が含まれます。

nakama とは?

このスキルは、GitHubのプルリクエスト(PR)説明文を、ADHDを持つ開発者やレビュアーが一目で把握できる「スキャン可能」なフォーマットに整形します。従来の長文のPR説明とは異なり、変更の結果(アウトカム)を最初に1行で提示し、Before/Afterを2行で対比、リスクを理由付きで最大3つまで箇条書きし、ロールバック条件を1行で示します。テスト計画も具体的な実行コマンドと成功数を記載することを推奨し、レビュアーが素早くリスク評価と検証を行えるよう設計されています。このスキルは主にNakamaリポジトリ内のすべてのPR(エージェント作成、人間作成を問わず)にデフォルト適用され、`ce-commit-push-pr` 経由でのPR作成時にも自動で読み込まれます。gh CLIを使用してPR本文を一時ファイルに書き込み、`--body-file` オプションで適用します。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/ahmadrosid/nakama/tree/HEAD/.agents/skills/adhd-pr-description

Installed? Explore more ライティング&編集 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

プレビュー

スキル README より

Compound Engineering
HARNESS

ドキュメント

ADHD PR説明文

このリポジトリのデフォルトPR本文フォーマット。 レビュアーは一目で説明を読み終えられるようにします。差分はすでにGitHub上にあるため、ファイルの移動を改めて記述しないでください。

エージェントは、NakamaのPR説明文を作成または書き換える際(ce-commit-push-pr 経由も含む)には、必ずこのスキルを読み込んでください。本文の形状はここから取得しますが、実際の主張(アウトカム、リスク、検証内容)は差分から収集してください。

形状(必須)

## Summary

<1行: 誰が何をして → どうなるか。変更内容が専門用語でない限り、専門用語による曖昧さは避ける。>

**Before:** <1行 — 以前の動作やコスト>
**After:** <1行 — 新しい動作。リスク評価に役立つ場合は、主要な関数やパス名を記載>

Why safe:
1. <理由>
2. <理由>
3. <理由>   <!-- 最大2~3項目。言うことがなければ#3は削除 -->

Only re-add / follow up if <1つの残余リスクまたはロールバックのトリガー>。

## Test plan
- [x] <すでに実行したコマンド>(<N> pass)
- [ ] <人間が2分以内に実行できる手動確認1つ>

テスト計画の後にオプションとして(ワークフローがCompound Engineeringバッジを想定している場合、維持):

---

[![Compound Engineering](https://img.shields.io/badge/Built_with-Compound_Engineering-6366f1)](https://github.com/EveryInc/compound-engineering-plugin)
![HARNESS](https://img.shields.io/badge/<MODEL_SLUG>-000000)

ルール

  1. リード = アウトカム。 最初のSummary行は新しい世界を表し、「このPRは~を削除する」ではありません。
  2. Before/After = 2行。 ラベルは太字。段落で囲まない。
  3. Why safe = 番号付き、最大3つ。 本文全体の箇条書きは最大5つに制限。それ以上ある場合は、意思決定に影響するものだけを残す。
  4. 1つの残余リスク。 この変更を取り消すことになるケースを1つ挙げる。本当にない場合は省略。
  5. 差分の詮索禁止。 ファイル、行数、または「エクスポートも整理した」をストーリーとして列挙しない。ただし、それがリスクそのものである場合は除く。
  6. テスト計画 = 実行可能。 合格数を添えたチェック済みコマンドを優先。1つの未チェックの手動確認。
  7. タイトルは従来通り。 type(scope): imperative — 短く。本文がこの形状を持ち、タイトルに絵文字やエッセイは不要。
  8. gh で適用。 本文を一時ファイルに書き込み、gh pr edit <n> --body-file … または gh pr create --body-file … を使用。--body "$(cat …)" は使用しない。

ゴールデン例

この密度に一致させる:

## Summary

組織メモリの提案を承認 → バレットが `MEMORY.md` に追加される。LLM呼び出しなし。

**Before:** 決定論的マージ、その後オプションでファイル全体をモデルが書き換え。
**After:** 決定論的マージのみ(`applyApprovedOrgMemoryBullet`)。

Why safe:
1. 重複排除と置き換えは既にその関数内で動作中
2. LLMパスは既に決定論的結果にフォールバックしている
3. −230行、同じ承認結果

Only re-add an LLM rewrite if contradictory bullets start surviving approve.

## Test plan
- [x] `bun test packages/agent/src` (80 pass)
- [x] `bun test apps/server/src/services/org-memory-service.test.ts` (15 pass)
- [ ] 保留中の提案を1つ承認(固定 + 最近のログ)— バレットが以前と同様に追加されることを確認

アンチパターン

やってはいけないやるべきこと
複数段落のSummary1行のアウトカム + Before/After + Why safe
「このPRは~を目的としています」/「~するために」動詞またはユーザーのアクションで始める
Summaryの下にネストした###フラットな## Summary + ## Test planのみ
削除したファイルをすべて再度記述残余リスクのみ
曖昧な「テスト合格」正確なコマンド + 合格数

ワークフロー

  1. PRの差分/コミットを読む(gh pr view、git diff base...HEAD)
  2. 名前: アウトカム、Before、After、最大3つのWhy-safe、1つの残余リスク
  3. テンプレートを埋める — 差分がすでに証明している文は削除
  4. --body-file で適用
  5. PRのURLを返信(「タイトルを詰めてほしい場合は言ってください」は有用な場合のみ追加)

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

関連スキル