@shinaps/skills 0.11.0

package/plugins/shinaps-codex/skills/release/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: release
+description: プロジェクトの公開手順と完了条件に従ってリリースし、対象バージョンが利用可能なことを検証する。公開・配布・本番デプロイを依頼されたときに使う。
+---
+
+## 作業記録の保存先
+
+作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
+
+既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
+
+# リリースして利用可能性を確かめる
+
+## プロジェクトの条件を読む
+
+適用される `AGENTS.md`・`CLAUDE.md` と参照先、README、CI、既存スクリプトから、今回の対象・必須検証・禁止事項を確認する。現在の依頼と合意済みの条件を引き継ぎ、一般的な推奨をプロジェクトの必須条件に格上げしない。条件同士が矛盾し結果を左右する場合だけ一問ずつ確認する。任された実装判断は進める。
+
+既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
+
+## 公開前に条件を確定する
+
+対象環境・配布先・ソースrevision・成果物のバージョンと、成功を判断する操作・証拠を確定する。リポジトリのリリース手順を使い、既存CIや証拠形式があれば再利用する。専用のJSON形式や新しい検証基盤を導入すること自体を必須にしない。
+
+完了条件は公開物の性質と変更の影響から決める。Web、配布アプリ、ライブラリ、CLIで同じ端末検証を強制しない。マイグレーション、バックエンド連携、実機導入、配布ストアの処理、運用ログは、対象に関係する場合の条件として扱う。不要な項目を形式的に増やさず、必要な条件を使えるツールに合わせて弱めない。
+
+公開・認証・破壊的操作の許可はユーザーの依頼と実行環境の規則に従う。リリース依頼から別環境への展開、データ削除、課金変更、対外告知、ストア審査提出の許可を推測しない。
+
+## 実行
+
+1. Git状態、対象revision、必要な検証と公開先を確認する。無関係な未コミット差分を成果物に混ぜない。
+2. プロジェクトが定める検証とビルドを行い、公開する成果物の識別情報を記録する。
+3. 文書化された公開経路を実行する。処理中・配布可能・利用確認済みを区別する。
+4. 同じrevision／バージョンに対して完了条件を確認する。関連システムがある場合は整合も確認し、別revisionの正常応答を今回の成功と扱わない。
+5. 失敗した段階、外部への反映状況、復旧手順を保持する。再試行前に反映状態を確認し、二重公開を避ける。復旧も既存の許可範囲で行う。
+
+## 完了
+
+公開したidentity、配布先、確かめた主要操作・証拠、未確認条件を示す。必要な条件が残れば「公開済み・利用確認未完了」など実態を報告する。人間の確認が必要ならその段階から再開し、完了済みの公開を繰り返さない。証拠には秘密情報を含めない。

package/plugins/shinaps-codex/skills/review/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: review
+description: 差分・PR・指定コードを根拠付きでレビューする。Shinapsのレビュー担当を利用できる場合は一次レビューと指摘の検証を分ける。
+---
+
+# レビュー
+
+対象プロジェクトのAGENTS.md、既存設計、依頼範囲を確認する。作業ツリーをレビューする場合はステージ済み・未ステージ・未追跡の関連変更を含める。PRやブランチを指定された場合はその比較範囲を使う。
+
+Shinaps AIのルール検索が利用できる場合は関連するルールを取得し、指摘の根拠に含める。利用できない場合はルール照合が未確認であることを報告する。コード自体のレビューは続けられる。
+
+委託が許可され、shinaps-reviewerが登録されている場合は、対象・差分・背景・取得済みルールを渡してレビューを依頼する。利用できない場合は現在のセッションで同じ観点を確認し、独立レビューとは報告しない。エージェントの追加委託やworktree作成を暗黙に許可しない。
+
+指摘の独立検証が依頼・許可の範囲に含まれる場合は、登録済みのshinaps-review-validatorへ元の対象と一次指摘を渡す。外部APIの仕様が判断を左右する場合はshinaps-tech-surveyorで調査し、具体的な推奨の出典をshinaps-survey-validatorで確認できる。委託の数や範囲をユーザーが制限した場合はそれに従う。
+
+返された指摘を実コードと照合してから、挙動への影響があるものを優先度順に報告する。対象箇所、発生条件、影響、最小の修正案を含める。推測と確認済みの事実、実施した検証と未実施を区別する。指摘を埋めるための好みの変更は加えない。
+
+修正・コミット・PR投稿はユーザーに依頼された範囲だけ行う。記録が必要ならプロジェクトの.shinaps/work/に保存し、.shinaps/.gitignoreに必要な除外を追加する。既存内容と追跡済みファイルは保持する。

package/plugins/shinaps-codex/skills/simplify/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: simplify
+description: 実装・設計・手順を目的と必要条件から見直し、不要な要素を削除して簡素化する。実装後のセルフレビュー前や、複雑さの見直しを求められたときに使う。
+---
+
+## 作業記録の保存先
+
+作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
+
+既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
+
+# 目的から見直して減らす
+
+## プロジェクトの条件を読む
+
+適用される `AGENTS.md`・`CLAUDE.md` と参照先、README、CI、既存スクリプトから、今回の対象・必須検証・禁止事項を確認する。現在の依頼と合意済みの条件を引き継ぎ、一般的な推奨をプロジェクトの必須条件に格上げしない。条件同士が矛盾し結果を左右する場合だけ一問ずつ確認する。任された実装判断は進める。
+
+既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
+
+## 判断と実行
+
+- 目的、守る外部契約、現在の実装方法を区別する。今の構造を要件として正当化しない。
+- 根拠の弱い前提、不要な分岐・互換層・重複、丸ごと消せる手順を実物から探す。削除 → 簡素化 → 最適化 → 自動化の順で考え、必要な段階だけ実施する。
+- 利用箇所と契約を調べ、依頼範囲内で挙動を保つ削除を適用する。行数だけを減らして責務を混ぜない。仕様を変えることで簡単になる場合は、変わる挙動と推奨案を示して先に確認する。
+- 変更の影響に合う検証を行う。問題がなければ変更を作らず終了する。
+- 削ったもの、判断理由、確認結果を短く報告する。コミットや公開はこの工程の許可に含めない。

package/plugins/shinaps-codex/skills/spec/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: spec
+description: 曖昧な要望を対話と既存実装・実現可能性の調査で具体化し、実装へ引き継げる仕様にする。
+---
+
+# 仕様策定
+
+対象プロジェクトの指示・既存実装・過去の決定を確認して、既に決まっていることを再質問しない。目的、利用者、期待する挙動、制約、範囲外を一問ずつ詰める。受入条件は守るべき性質で書く。
+
+既存構造との適合と技術的な実現可能性を調べる。外部仕様が判断に必要なら公式資料を確認する。候補の数を埋めず、目的に合う推奨案と意味のある代案を示す。プロトタイプは依頼された範囲で必要な場合に行い、仕様相談を本番への変更へ拡大しない。
+
+委託が許可されている場合、登録済みのshinaps-explorer、shinaps-tech-surveyor、shinaps-survey-validatorに調査を依頼し、shinaps-spec-writerで結果を構造化できる。提供されていない担当やツールは仮定せず、同じ観点を現在のセッションで確認する。
+
+利用可能なShinapsルールを制約の根拠に含める。利用できないときはルール照合を未確認とし、実現可能性や仕様確定に残る影響を明記する。
+
+合意した仕様を.shinaps/work/specs/のspec.mdへ保存する。.shinaps/.gitignoreに`*`の除外を既存内容を保持して設定する。仕様には目的・範囲・挙動・受入条件・設計判断・根拠・未決事項を含める。実装依頼があれば$shinaps:devへこの記録を渡す。仕様作成だけの依頼で自動実装しない。

package/plugins/shinaps-codex/skills/verify-ui/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: verify-ui
+description: UI変更を対象プロジェクトの対応環境で実際に操作し、見た目と挙動を検証する。UI実装後や画面の動作確認を求められたときに使う。
+---
+
+## 作業記録の保存先
+
+作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
+
+既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
+
+# UIを使って検証する
+
+## プロジェクトの条件を読む
+
+適用される `AGENTS.md`・`CLAUDE.md` と参照先、README、CI、既存スクリプトから、今回の対象・必須検証・禁止事項を確認する。現在の依頼と合意済みの条件を引き継ぎ、一般的な推奨をプロジェクトの必須条件に格上げしない。条件同士が矛盾し結果を左右する場合だけ一問ずつ確認する。任された実装判断は進める。
+
+既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
+
+## 検証範囲を決める
+
+対応ブラウザ・端末、変更する操作、期待する性質、必須の証拠を既存仕様から決める。受入条件はケースの列挙ではなく「再表示しても保存した選択を保つ」のような性質で書き、代表的な操作で確かめる。
+
+特定ブラウザ、実機、Simulator、複数OSバージョンを一律に必須にしない。プロジェクトがPCブラウザのみを対象にするならその範囲で検証する。エンジン差・ハードウェア・入力方式が結果を左右する変更なら、その差を確認できる環境を選ぶ。必要な環境が使えない場合、別環境で通ったことを代替証拠にせず未確認として残す。対応範囲自体が不明で結論を左右する場合だけ確認する。
+
+## 実行と証拠
+
+1. 現在の画面と実装を確認する。余白や入力の問題がアプリ・ブラウザ・端末のどこに属するか切り分ける。
+2. プロジェクトが必要とする自動検証を実行し、対象の実画面で主要操作と関連する状態遷移を確かめる。DOMや内部状態の注入を操作成功の証拠にしない。
+3. レイアウトの欠け、重なり、フォーカス、再操作、保存・再表示など変更の影響する性質を確認する。動画や計測を必要とする動き・性能は静止画だけで合格にしない。
+4. 視覚的な判定にはスクリーンショットを残し、環境・操作・期待・観測結果を対応づける。明示された証拠の納品先がなければ `.shinaps/work/` 以下の今回の作業ディレクトリを使う。
+5. 発見した問題を直した場合は影響部分を再確認する。独立レビューは利用可能で許可され、効果がある場合に限る。
+
+## 完了
+
+定めた範囲で期待する性質を実画面から確認できたことを報告する。自動テストのみ・画面を開いただけ・スクリーンショットのみで操作を確認済みにしない。未確認事項と理由は完了範囲から区別する。実装・修正が依頼されていなければ、検証の依頼から変更許可を推測しない。