Menu
実装中の設計上の気づき・疑問・バックログ送りにしたタスクを spec/dev-journal.md に記録するスキル。USE WHEN: ユーザが「ジャーナルに書いて」「メモしておいて」「dev-journal に追記して」「これ記録して」「あとで見返せるようにして」「バックログに入れて」「後回しにしたい」など、実装中の気づきや先送りタスクの記録を依頼したとき。spec/dev-journal.md を読み書きするときは必ず参照すること。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
フレームワーク本体 (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
実装中の設計上の気づき・疑問・バックログ送りタスクの記録。