「helm」の検索結果

Use when independent bounded tasks benefit from delegation during implementation

日本語の概要は準備中です。原文の説明を表示しています。

Use when continuing implementation from an existing plan

日本語の概要は準備中です。原文の説明を表示しています。

Git worktree を使った並列開発時に使用。配置・ポート割当・環境コピー・クリーンアップを標準化する。

Use when recurring process failures, obsolete rules, or an explicit user request call for harness improvement.

日本語の概要は準備中です。原文の説明を表示しています。

git logからCHANGELOGとリリースノートを自動生成する。リリース作業時に使用。

フロントエンド実装時に使用。コーディング規約準拠。コンポーネント設計。

機能・サービス・要件・前提条件などプロジェクトの知識をドキュメント化する。新規機能/サービスを作るとき、または既存機能を変更するときに必ず実行。新規ならドキュメントを作成、既存があれば更新する。

DBマイグレーション作成時に使用。バージョン番号競合防止。mainブランチ確認必須。

UI実装後の検証時に使用。agent-browser CLIでブラウザ上の動作を手動検証する。「UIを確認」「画面テスト」と言われたら使用（プロジェクトの E2E スイート実行は quality-check Step 5（推奨度・範囲で自動実施または確認）/ server-startup が担当）。

Use when implementing any feature or bugfix, before writing implementation code

日本語の概要は準備中です。原文の説明を表示しています。

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

日本語の概要は準備中です。原文の説明を表示しています。

Use when a multi-step change needs explicit sequencing, dependencies, or a handoff

日本語の概要は準備中です。原文の説明を表示しています。

Use when selecting skills for a task or resolving how skill workflows apply

日本語の概要は準備中です。原文の説明を表示しています。

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

日本語の概要は準備中です。原文の説明を表示しています。

Use when arranging the project quality-check or investigating a concrete unresolved code concern

日本語の概要は準備中です。原文の説明を表示しています。

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

日本語の概要は準備中です。原文の説明を表示しています。

Use when verified implementation is ready for an integration decision or authorized integration

日本語の概要は準備中です。原文の説明を表示しています。

Use when independent tasks benefit from parallel work without shared state or sequential dependencies

日本語の概要は準備中です。原文の説明を表示しています。

Use before implementing any feature, behavior change, or refactor - settles requirements and design, then gets the design independently reviewed and approved by the user before code is written

日本語の概要は準備中です。原文の説明を表示しています。

変更内容からミューテーション/E2Eの推奨度を判定し、強く推奨・範囲が小さい・副作用なしのものは確認なしで実施し、それ以外は最後の報告で確認する。quality-check Step 5から参照実行されるほか、開発中の任意タイミングで単体実行できる。

実装前に呼ぶ。High/Medium リスク変更のテストオラクル（期待値の根拠）とファルシフィケーション項目を定義する。

開発サーバー・E2E・ブラウザ検証時に使用。既存プロセスを停止してからプロジェクト指定ポートで起動し、作業後に必ず停止する。

マージ前に必ず実行。静的チェック・テスト・体制レビュー（変更内容で決まる統合レビュアー＋反証型QA＋専門家最大1体、基本1サイクル）と追加テスト（test-recommendation）を実施し、通過後のみmainへのマージ・直接pushが可能。

ログ設計の妥当性チェック。一般的なログ基準と日本国内法的要件（電子帳簿保存法・個人情報保護法等）に基づき、ログ設計・実装を検証する。