メニュー
実装中の設計上の気づき・疑問・バックログ送りにしたタスクを spec/dev-journal.md に記録するスキル。USE WHEN: ユーザが「ジャーナルに書いて」「メモしておいて」「dev-journal に追記して」「これ記録して」「あとで見返せるようにして」「バックログに入れて」「後回しにしたい」など、実装中の気づきや先送りタスクの記録を依頼したとき。spec/dev-journal.md を読み書きするときは必ず参照すること。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
フレームワーク本体 (src/nyxpy/framework/) の仕様書を新規作成・レビュー・修正するスキル。Use when: ユーザが「フレームワークの仕様書」「framework spec」「コア機能の設計書」「Command / MacroBase / imgproc / logger 等の仕様」と言ったとき、または spec/agent/ 配下でフレームワーク関連の Markdown を扱うとき。フレームワーク層の公開 API・内部設計・テスト方針を所定フォーマットで執筆する。マクロ (macros/) の仕様書には macro-spec-writing スキルを使うこと。
マクロ仕様書の新規作成・レビュー・修正を行うスキル。Use when: ユーザが「仕様書を書いて」「specを作成」「仕様書レビュー」「仕様のテンプレート」と言ったとき、または spec/agent/ 配下のMarkdownを扱うとき。Nintendo Switch自動化マクロの設計仕様・実装仕様・テスト方針を所定フォーマットで執筆する。
Project NyX の PyPI release を計画・実行する workflow skill。USE WHEN: ユーザが PyPI / TestPyPI への公開、バージョン更新、release PR、v* tag、GitHub Actions publish、公開後 smoke check、release 手順の確認を依頼したとき。
作業ブランチを GitHub PR 経由で main にマージし、ローカル同期・ブランチ削除まで一括実行するワークフロースキル。USE WHEN: ユーザが「PRを出して」「マージして」「ブランチをまとめて」「mainに入れて」「PRクリーンアップ」など、作業ブランチの変更をリモートに反映したい意図を示したとき。push → PR作成 → squashマージ → ローカル同期 → ブランチ削除の全ステップを自動化する。
Project NyX のマクロ実装・修正・レビューを行うスキル。USE WHEN: ユーザが「マクロを作って」「マクロを直して」「macros/ 配下を実装」「resources/ の設定を追加」「NyX の MacroBase / Command を使う」「examples/macros を参考にしたい」など、Nintendo Switch 自動化マクロのコード・設定・テストを扱う意図を示したとき。仕様書だけを書く場合は macro-spec-writing を使う。
| name | dev-journal |
| description | 実装中の設計上の気づき・疑問・バックログ送りにしたタスクを spec/dev-journal.md に記録するスキル。USE WHEN: ユーザが「ジャーナルに書いて」「メモしておいて」「dev-journal に追記して」「これ記録して」「あとで見返せるようにして」「バックログに入れて」「後回しにしたい」など、実装中の気づきや先送りタスクの記録を依頼したとき。spec/dev-journal.md を読み書きするときは必ず参照すること。 |
実装中に発生する設計上の気づき・疑問・バックログ送りタスクを spec/dev-journal.md に時系列で蓄積するスキル。
仕様書にするほどでもないが、後から振り返れるようにしておきたい情報の置き場として使う。
spec/dev-journal.md の 1 ファイルに集約する## YYYY-MM-DD: {タイトル}
### 現状
{現在の実装・設計がどうなっているか}
### 観察
{何が問題か、何を改善できるか}
### 方針
{対応策・回避策、または先送りの判断理由}
##) + 日付 (ISO 8601) + タイトル###) で 現状 / 観察 / 方針 の 3 セクションを立てるedge アルゴリズム切替時のメッシュ再生成コスト)各セクションは一文で済むなら一文でよい。エントリ全体で 10 行以内を目安にする。
バックログ送りのタスクも同じ形式で書く。「方針」に先送りの理由と再検討の条件を記載すると、後から拾いやすくなる。
同じテーマで進展があった場合は、新しいエントリとして追記する。その際、前回エントリを 前回: YYYY-MM-DD タイトル として本文冒頭 (最初の H3 の前) に記載すると追跡しやすい。
spec/dev-journal.md の存在を確認する。なければ初期テンプレートで作成するファイル新規作成時は以下の内容で作成する:
# Dev Journal
実装中の設計上の気づき・疑問・バックログ送りタスクの記録。