feature-workflow

本リポジトリの必須開発フロー(機能設計→詳細設計[ラバーダック]→テスト作成[ラバーダック]→TDD実装(Red/Green/Refactor)→テスト(+E2E)→振り返り[ラバーダック])をオーケストレーションする。Use this skill whenever the user asks to implement a new feature, start a feature, fix a bug with proper process, or says 新機能を実装, 機能を追加, 設計から始めて, feature実装, ちゃんとした手順で実装して, TDDで実装.

インストールへ移動

リポジトリ: runceel/wsl-containers-desktop
ソースの最終更新活動: 2026年7月9日 06:24
検出された SKILL.md の言語: 日本語
スター: 11
フォーク: 0

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。

npx skills add https://github.com/runceel/wsl-containers-desktop --skill feature-workflow

コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。

ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md

ソースの指示 · 読み取り専用プレビュー

検索に戻るインストールに戻る

store-release-workflow

本リポジトリの新バージョンをMicrosoft Store向けに準備し、最新origin/mainの確認、Semantic Versioning、テスト、manifest更新、x64/ARM64 msixupload生成、バージョン専用PR、GitHub Release、英語のStore新機能文まで安全にオーケストレーションする。Use this skill whenever the user asks to prepare or publish a new version, create a Microsoft Store release, create an msixupload and GitHub Release, bump the Store package version for release, or says 新バージョンをリリース, MS Storeリリース, Storeパッケージを作ってRelease, リリース作業. Do not use for local-only MSIX packaging without a release.

2026-07-17

adr-workflow

設計判断・プロセス決定をADR (Architecture Decision Record) として作成・更新する具体的な手順。Use this skill whenever the user asks to record a decision, write an ADR, or says ADRを書きたい, 設計判断を記録したい, ADR作って, この決定を残したい.

2026-07-02

design-doc-maintenance

docs/design配下の設計ドキュメントを、経緯を含めない最新スナップショットとして更新する手順。Use this skill whenever the user asks to update design docs, keep documentation current, or says 設計ドキュメントを更新, design docを直して, アーキテクチャドキュメントを最新化して.

2026-07-02

このリポジトリのすべてを見る

Feature Workflow（機能開発フローオーケストレーション）

本リポジトリでは、機能追加・仕様のある変更を行う際、必ず以下の6フェーズを順番に実施する（AGENTS.md の「開発フロー」節の実行手順版）。

単純な機械的修正（タイポ修正等）は対象外。quick-fix agent（ADR-0004）を使う。

フェーズと使うツール

フェーズ

やること

使うagent/skill

機能設計

何を作るか、スコープ、ユーザー価値を明確にする

（このagent自身で会話しながら詰める）

詳細設計

技術的な設計判断（層構成上の配置、インターフェース設計等）を行う

task agent_type: rubber-duck でレビューを受ける

テスト作成

詳細設計の仕様をMSTestのテストとして書き下す（まだ失敗させない）

task agent_type: rubber-duck でテスト内容をレビューする

実装(TDD)

Red→Green→Refactorを1振る舞いずつ繰り返す

tdd-red.agent.md（ADR-0008の条件でFlash既定）→ tdd-green.agent.md（ADR-0016によりFlash既定・新規設計判断時はベースラインへエスカレーション）→ tdd-refactor.agent.md（ベースライン）

テスト

単体テストに加え、UIに関わる変更は自動E2Eも行う

既存の winui-ui-testing skill（winui plugin）

振り返り

設計判断・実装の妥当性をレビューし、必要ならADR/design docを更新

task agent_type: rubber-duck、必要なら adr-writer agent

各フェーズの完了条件 (Definition of Done)

機能設計: スコープと非スコープが明文化され、ユーザーの合意が取れている。

詳細設計: rubber-duck の重大な指摘が解消済み。ADR化が必要な決定は洗い出し済み（必要なら adr-workflow を使ってこの時点でADRを書いてよい）。

テスト作成: rubber-duck のレビューで「仕様の抜け漏れ」の指摘が解消済み。加えて、具体的な入出力・アサーション値・エッジケース（表形式等）まで確定していること（ADR-0008 / ADR-0016により、ここが確定していないと後続のTDD Red/Greenフェーズを低コストモデルで進められないため）。

実装(TDD): 対象の振る舞いすべてがGreenで、Refactor後もGreenを維持している。

テスト: 単体テスト・（該当する場合）E2Eテストがすべてパスしている。

振り返り: rubber-duck の指摘を反映済み。ADR・docs/design/ が実装と一致するよう更新済み（design-doc-maintenance を使う）。

進め方の原則

フェーズを飛ばさない。特に「テスト作成」を「実装」より先に行うことを厳守する（ADR-0002）。

1回のTDDサイクルで扱う振る舞いは1つ。複数の振る舞いがある機能は、フェーズ2〜4を振る舞いごとに小さく繰り返す。

ラバーダックは task ツールで agent_type: "rubber-duck" を使う。それぞれのタイミングで、「何をレビューしてほしいか」（設計内容 / テスト内容 / 実装結果）を明示してから依頼する。

層構成（Domain/Application/Infrastructure/Presentation）への配置は ADR-0005 と csharp.instructions.md に従う。