Happy Coding

Plugin happy-coding in RyoMurakami1983/happy-ai-work. Commands read from the repo's manifest — yesterday.

Skills (22)

• business-understanding-survey

  数理最適化や業務システムの現場に聞く質問を、根拠資料から設計する。目的・制約・選好・例外を確認するアンケートに使う。

• ci-debug

  GitHub Actionsなどの失敗したCIチェックをログから切り分け、根本原因と最小修正を特定する。PRチェック失敗、workflow失敗、ローカルでは再現しないCI障害を調査するときに使う。

• debug-and-fix

  特定の不具合、回帰、flaky failure、性能劣化について、症状を検出できる再現loopを作り、根本原因を証拠で絞り、最小修正と回帰確認まで完了する。原因説明だけでなく、直してgreenにする依頼で使う。

• deep-review

  実装者と独立した視点で差分をレビューし、再現可能で高信頼な指摘だけを重要度順に返す。PR前の深いレビュー、回帰・境界・テスト不足の確認、または別レビュアー視点が必要なときに使う。

• domain-modeling

  合意済みの目的・要件を、ドメイン用語、目的別モデル、境界、業務ルール、不変条件、状態遷移へ構造化する。用語の整理だけにも、モデルと業務上の契約の作成・見直しにも使う。目的・要件の確定はto-prd、module・interface・技術選定はtechnical-designへ渡す。

• dotnet-framework-bridge

  .NET Framework 4.xのlegacy実装を残しながらモダン.NETへ段階移行する境界を設計・検証する。共有contract、netstandard、multi-target、adapter、別processのどれで橋渡しするか判断するときに使う。

• dotnet

  C#／.NETリポジトリのSDK・solution・project・build contractを読み、既存規約を尊重して実装・テスト・検証する。.NETコードの変更、環境構築、移行、ビルド診断で使う。WPF固有の画面設計はwpfを使う。

• html-questionnaire

  回答をJSONで受け取れるオフラインHTML質問票を作る。質問内容が決まり、フォームでまとめて渡したいときに使う。

• implement

  合意済みの要求・設計・issueから実装順とvertical slicesを計画し、許可された範囲をTDDと検証で完了する。 実装計画だけの依頼にも使い、その場合は計画で停止する。PR作成やふりかえりは別skill。

• interview-with-docs

  文書や既存repoを根拠に要件をインタビューし、用語と境界を整理する。資料を基に仕様を固めたいときに使う。

• nuget-local

  自作NuGet packageをローカルfeedへpackし、consumer repoでsource・version・restore・buildを分離して検証する。未公開packageの動作確認、legacy packages.config、PackageReference、pack／consume失敗の切り分けで使う。

• pr-delivery

  「マージして」「merge PR」という対象PRの明示依頼、またはマージ済みPRの「マージ後整理」を受け、最新checks・マージ結果・base同期・安全な対象branch/worktree整理・結果報告まで進める。PR作成、review、CI監視だけの依頼ではマージしない。

• python

  Pythonリポジトリの環境・依存・lint・型検査・テスト契約を読み、既存ツールを尊重して安全に実装またはセットアップする。Pythonコード、pyproject、スクリプト、テストの変更で使う。

• repo-onboarding

  未知のリポジトリを変更せずに調査し、目的、構造、技術、build／test契約、重要境界、未確認事項の最初の地図を作る。新しいrepoへ入るときや実装前のorientationで使う。bootstrap変更は扱わない。

• rust

  Rust／Cargoリポジトリのworkspace、toolchain、feature、format、Clippy、test契約を読み、所有権・エラー・unsafe境界を保って実装またはセットアップする。RustコードやCargo設定の変更で使う。

• tauri

  Tauriデスクトップアプリのfrontend／Rust境界、capability、Windows toolchain、bundle、sidecarを実装・診断・配布検証する。Tauri導入、Windows build、外部binary、installer、packaged-only failureで使う。

• technical-design-review

  実装前の技術設計を独立レビューし、根拠ある指摘、理由付きの推奨、利用者に必要な判断と次の一歩を示す。目的・要件、契約、変更容易性、依存・安全境界を確認する。設計作成はtechnical-design、実装差分はdeep-reviewが担当する。

• technical-design

  合意済みの目的・要件から、module責務、public interface、data flow、security boundary、trade-offを決め、根拠・変更シナリオ・契約を追える設計を作る。構造判断とレビューへ渡す設計資料の作成・更新に使い、必要ならアーキテクチャ・UML図入りHTMLを併用する。独立レビューの判定、実装計画、実装は扱わない。

• to-prd

  会話と確認済み資料の文脈から目的、目的達成の条件となる要件、検証可能なAcceptance Criteriaを対応づけ、scope・制約・未確定事項とともにPRDへ整理する。何をなぜ作るかを合意・保存し、必要に応じて読解用のオフラインHTMLも作る。モデルや技術構造の設計、実装計画は扱わない。

• typescript

  TypeScript／TSXリポジトリのpackage manager、tsconfig、module方式、lint、test、build契約を読み、型安全と実行時境界を保って実装またはセットアップする。Node.jsやfrontendのTypeScript変更で使う。

• ui-design

  既存または計画中のアプリUIを、人間中心設計に基づいて批評・再設計し、実装可能な画面設計と実行時検証へ落とす。画面の使いにくさ、状態、command hierarchy、アクセシビリティを扱うときに使う。

• wpf

  WPFアプリのXAML、binding、resource、MVVM、UI thread、設定保護を既存構成に合わせて実装・診断する。WPF画面、ViewModel、command、validation、デスクトップ設定を扱うときに使う。一般的な.NET変更だけならdotnetを使う。

Similar plugins