shinnn-app

API のエンドポイントを 1 つ追加する 6 手順（API 定義 → テーブル → service → router と controller → テスト → docs）。「API を足したい」「エンドポイントを追加」で起動

画面を 1 つ追加する 7 手順（受入条件と API 定義 → 置き場所とルート → ページ → 取得と表示 → 入力 → スタイル → テスト）。「画面を追加したい」「新しいページを作る」で起動

リポジトリ全体の型検査・lint・テストと、受入条件および API 定義のカバレッジを確認する。範囲を絞ったビルド・lint・テストの仕方と、落ちたときの直し方も持つ。/shinnn-app:pr が PR を出す前に 1 回呼ぶ。「チェックして」「テストを通して」「壊れていないか確認」「型エラーを見て」「lint を通して」「このテストだけ実行」でも起動

変更したコードを 3 つのレビューエージェントで並列に見て、Critical / Warning / Info に分けて報告する。PR を出す前のセルフレビューに使う。「レビューして」「セルフレビュー」「指摘を洗い出して」で起動

DB のスキーマ変更を drizzle-kit generate で migration にし、内容を確認してから適用する。「テーブルを追加した」「マイグレーション」「DB のスキーマを変えた」で起動

開発用のサーバー群（PostgreSQL・API サーバー・画面）を起動・停止する。引数で対象を選ぶ（server / client / all / stop）。「開発サーバーを起動」「動かして確認したい」「止めて」で起動

作りたいことを受け取り（1 つでも、まとめていくつでも）、PR 1 本に収まる大きさの Issue に分けて順番を決め、1 本ずつ Issue の作成 → 仕様書への反映 → ブランチ作成 → shared → server → client → テスト の順で実装する。文言 1 つの変更や不具合の修正もこのスキルで進める（作業中のブランチの lint・テスト・レビューの指摘の直しは含まない。それは check と pr）。「機能を追加したい」「〜を作りたい」「〜を変えて」「〜を直して」「不具合を直して」「こういうアプリがほしい」「続きをお願い」で起動

引き継ぎの完了定義を満たしているかを項目ごとに判定し、足りないものを一覧にする。開発の区切りや保守の引き渡し前に実行する。「引き継げる状態か」「完了定義の確認」「引き渡し前チェック」で起動

実装をわざと壊して、受入条件のテストが本当に落ちるかを確かめる。壊す内容を 1 つずつ当て、狙ったテストが落ちることを見てから元に戻す。受入条件を足した・変えた PR と、不具合を直した PR では必ず使う（`pr` の手順 1 が呼ぶ）。「テストが効いているか確かめて」「変異テスト」「このテストは空振りしていない？」でも起動

変更をコミット・プッシュしてドラフト PR を作り、レビューが収束するまで回す。マージの方針が self-review なら CI の通過後にマージまで行う。PR 本文には対応 Issue（Closes

PR を出したあとに、詰まり・学び・次に試すの 3 行を Issue にコメントし、引き継ぎに関わることを「引き継ぎメモ」Issue に追記する。/shinnn-app:pr が報告の後に呼ぶ。「振り返り」「終わったので整理」「今日の作業をまとめて」でも起動

セッションで分かった知見を棚卸しし、スキル・ドキュメント・rules・設定のどこに書くかを振り分けて反映する。/shinnn-app:feature が PR を出し終えて止まるときに 1 回呼ぶ。「知見をまとめて」「手順を残したい」「同じことで詰まらないように」でも起動

アプリの初回セットアップを対話で行う。空のフォルダでは同梱のテンプレートを展開して git と GitHub のリポジトリを用意する。テンプレートを展開した後は、テンプレートの選択・環境の検出・必須項目の確認・選択項目の決定・適用までを 1 回で通す。再実行すると選択の変更を差分の PR にする。「セットアップ」「初期設定」「最初に何をすればいい」「セットアップの選択を変えたい」で起動

プラグインが配布するルール（規約の rules・CLAUDE.md 雛形・アプリ作り方ガイド・権限の設定・git のフック・コミット時の整形の設定・確認のスクリプト・ワークフロー・PR テンプレート）の更新を、リポジトリへ取り込んで PR にする。標準バージョンに差があるときに実行する。「ルールを更新」「決まりごとを新しくして」「標準を更新」「rules を最新に」「バージョンが古いと言われた」で起動

規約・構成・書き方の「なぜそうなっているのか」を、仕様書・CLAUDE.md・rules・設計判断の記録を根拠に、平易な日本語と before / after で説明する。「なぜ」「どうして」「この決まりの理由は」「ここは何を見ればいい」で起動