シェルコマンドの実行、ファイル読み込み、URL の取得、検索、データの解析や変換を行うときに、 経路を通常のツールと context-mode の ctx_ ツールのどちらにするか判断するために使う。 context-mode が接続されている場合に適用する。ctx stats や ctx doctor といった "ctx" コマンドにも使う。
superpowers-conventions
superpowers の skill (brainstorming、writing-plans、subagent-driven-development、 executing-plans) を動かすとき、それらが作る design と plan のファイルを保存する、扱うとき、 plan に ADR や設計文書を作る task を書くとき、それらを使った作業の PR を作るときに使う。
実行スコア 未検証
インストール方法を見る含まれるファイル(1)
- SKILL.md3.9 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
superpowers-conventions
目的
作業の順序は superpowers に従う。この skill は、superpowers が作る design と plan のファイルについて、 保存先、ユーザーの承認を待つ時点、plan に入れる文書の完成文を文書規約に照らす時点、コミットしないこと、 GitHub への記録の仕方を決める。
保存先
design と plan の保存先は brainstorming と writing-plans の既定に従う。リポジトリの文書規約が作業途中の 成果物の置き場所を別に定めていても、そこへ移さない。
承認
- design のファイルを書いたら止まり、ユーザーにレビューを頼む。承認されるまで writing-plans を始めない
- plan のファイルを書いたら止まり、ユーザーにレビューを頼む。承認されるまで実装を始めない
- 承認はチャットの要約ではなくファイルに対して受ける。パスを示して待つ
文書を作る task
plan に ADR や設計文書を作る task があるときは、writing-plans の既定どおり、plan にその文書の完成文を 入れる。承認後に実装する側は plan の文を写すので、文書の内容を規約に照らす場は plan を書く時点になる。 plan を書く側は、完成文を書く前に doc-conventions を読み、ユーザーにレビューを頼む前に完成文を doc-conventions で照合する。照合の観点は doc-conventions に従い、ここには書かない。
作業場所と統合
plan の task、step、全体の制約、合否の基準のどこにも、作業ブランチや worktree を作る、選ぶ、切り替える 指示を書かない。作業する checkout を指定する制約 (「primary checkout で作業する」など) と、この作業の ブランチの push、PR の作成、merge も書かない。
作業場所は plan を実行する skill が using-git-worktrees で用意し、統合は finishing-a-development-branch が 扱う。plan にも書くと同じ作業を二重に指示することになる。作業場所と統合を自分で決める無人の実行環境に plan を渡したときは、plan の指示がその契約とぶつかる。
PR の本文に必ず入れる事柄があるときは、task ではない節 (「PR に書くこと」など) に書く。
コミットしない
docs/superpowers/ と .superpowers/ の下のファイルはコミットしない。gitignore されていない
リポジトリでは、git add -A のような一括の stage でも含めない。
GitHub への記録
ユーザーがこの作業の一部として design と plan を GitHub に記録するよう求めたときは、次の時点で gh-ops を使ってコメントとして投稿する。書き込みに要るユーザーの明示的な指示は CLAUDE.md が定める。 この節は、その指示があるときの投稿の時点と内容だけを決める。
- design、issue から始めた作業: plan の承認後、実装を始める前に issue に投稿する
- design、issue から始めていない作業: PR を作った直後に PR に投稿する
- plan: PR を作った直後に PR に投稿する
投稿する前に次の 2 点を済ませる。
- 本文をファイルの最終状態に合わせる。design と plan は書いた後に変わっていることがある
- 単体で読めるようにする。1 行目に主題を書き、git 管理外のファイル (design と plan のファイル自身、 作業メモ) への参照は本文に取り込むか削る
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
コメント
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
同じリポジトリのスキル
描く内容に合った図の種類を選んで図を書く。Mermaid の図、AWS の構成図、 マインドマップ (markmap。Mermaid ではない) を書く、直す、読み直すときに使う。
文書を書く、置き場所を決める、配置をレビューするときに使う。Markdown の書式、 ADR の作法、文書の層ごとの役割と正本の原則を扱う。
GitHub の Issue の作成、Issue へのコメント、draft PR の作成、PR へのレビューコメントの追加に使う。
PR のレビューコメントを解決する、または対応するときに使う。
コミットを頼まれたとき、plan のタスクを 1 つ終えたとき、まとまったコードの変更を 1 つ終えたときに、 次の作業に移る前に使う。