Skill.md検索

変更差分を分析して、11種類のprefix（add/fix/docs/refactor/test/chore/perf/build/ci/revert/style）から最も適切なものを自動判定し、コミットメッセージを作成できます。 1コミット1目的の原則に従い、複数の異なる目的を含む変更を検出して分割を提案できます。 日本語でコミットメッセージを作成し、変更内容の「なぜ」を簡潔に記述したサマリーと詳細本文（修正ファイル列挙）を自動生成できます。 コミット前のチェックリスト（差分確認→prefix根拠の説明→1目的確認→メッセージ簡潔性→ファイル記載→動作確認）を実行し、品質を担保できます。 Gitの履歴を見やすく保ち、プロジェクト管理を効率化したい開発者 コミットメッセージのルール（prefix・形式・本文の構成）を統一したいチームリーダー コミットメッセージから変更内容を素早く理解し、レビューやバグ追跡を高速化したい人 11種prefixの定義：add（ユーザー価値の増加）、fix（バグ修正）、docs（ドキュメント）、refactor（振る舞い不変の改善）、test（テスト追加・修正）、chore（雑務）、perf（パフォーマンス）、build（ビルド・依存）、ci（CI/CD）、revert（コミット取消）、style（フォーマット）。基本方針は1コミット1目的・差分確認必須・日本語・主目的で判定・迷時のルール（fix>add>refactor>chore）。メッセージ形式は: と本文（要点1-3行+ファイル列挙）。実行フロー：①git status/diff確認→②目的を1文定義→③prefix判定表で選定→④ステージング整理→⑤git commit実行。NG例（曖昧なsummary・無関係な変更混在・本文と主目的不一致・巨大コミット未分割・長い詳細）と実行前チェックリスト（差分確認・根拠説明可・1目的確認・簡潔性・ファイル記載・動作確認）を記載。

フィードバックを3種類に自動分類：バグ、微調整、新機能を判定し、対応方法を自動決定します。UI/UXの微調整依頼に即座に対応できます。 微調整をTDDで実装：Red-Green-Refactorサイクルに従いながら、ユーザーの要望を反映した変更を計画・実装します。 ステアリングファイルへの自動記録：対応内容をプロジェクトの進捗管理ファイル（tasklist.md）に新フェーズとして自動追加し、履歴を残します。 品質チェックの自動実行：pytest、ruff、mypyなどの自動検証ツールで修正品質を確保し、すべてのテストをパスさせます。 ユーザーへの完了報告を自動生成：対応内容、変更ファイル、品質チェック結果をまとめた報告文を作成します。 プロダクトマネージャー、デザイナー：ユーザーからの「ここをもう少し〜」という微調整依頼に迅速に対応したい人 開発チームリード：フィードバック対応を構造的に進め、進捗を可視化したい人 フルスタック開発者：実装中・実装後の軽微な変更をTDD規律を守りながら対応したい人 フィードバックを3つに分類：バグ（修正フロー）、微調整（このスキルで対応）、新機能（別スキル）。微調整対象は、HTMLタグ変更、テキスト表現調整、スペーシング・レイアウト調整、1〜2時間で完了する軽微な変更。新機能は新フィールド追加、新APIエンドポイント、大規模アーキテクチャ変更を除外。ステップ2で最新ステアリングディレクトリを特定、tasklist.mdを読み込んで現在フェーズ番号を確認。ステップ3でtasklist.mdに追加フェーズを記録、タイトルに「（ユーザーフィードバック対応）」を含める、背景セクションでユーザーフィードバックを引用、TDDサイクル（RED→GREEN→REFACTOR）を必ず含める。ステップ4でREDで失敗テストを先に書き、GREENで最小限の実装、REFACTORでコード品質改善。ステップ5でタスク完了時にチェックマークを付け振り返りセクションに追記。ステップ6でユーザーに対応内容、変更ファイル、品質チェック結果（pytest、ruff check）を報告。

型チェック・リント・テストを一括実行: mypy（型検査）、ruff（コードスタイル・セキュリティ検査）、pytest（ユニットテスト）を順序立てて実行し、品質基準をクリアしたコードのみ完成とできます。 既存バグを実装前に修正してクリーンアップ: 実装開始前に mypy と ruff で既存コードをチェックし、混在するバグを先に解消することで、実装中のデバッグ時間を大幅削減できます。 Ruff違反を自動修正＋優先度分類: 自動修正可能なエラー（import順序など）を自動処理し、手動修正が必要なエラーをセキュリティ・複雑度・命名規則などの優先度で分類して効率的に対応できます。 コード修正後の自動テスト再実行: Ruff や型エラーの修正でコードが変更されたら自動的にテストを再実行し、既存機能が壊れていないことを確認できます。 Pythonバックエンド開発者: TDD（RED/GREEN/REFACTOR）のサイクルで、各フェーズ完了時に軽量な品質チェックを自動実行したい。 チームリード: コード品質を統一し、PR レビュー時の指摘を最小化したい。 新入エンジニア: Ruff違反や型エラーの修正方法を段階的に学べます。 CI/CD 担当者: ローカルでの品質チェックを標準化し、本番前の問題を事前防止できます。 品質チェックはステップ0（実装前）とステップ4（実装後）で実行されます。ステップ0では①mypy src/ で型エラー検出②ruff check src/ でスタイル・セキュリティ問題検出③エラー発見時は修正して再チェックする流れです。ステップ4では①pytest tests/ -v でテスト実行②ruff check で違反確認③ruff check --fix で自動修正④残りのエラーは手動修正（セキュリティ S・複雑度 C90・print文 T20・命名規則 N などの優先度順）⑤ruff format src/ でフォーマット適用⑥pytest tests/ -v で修正後のテスト再実行の全プロセスを実施します。完了条件は pytest で全テストパス、ruff check で「All checks passed!」、mypy で「Success: no issues found」の三点です。

PRDと機能設計書の要件を技術的に実現するアーキテクチャ設計書を作成できます。 システム構造とテクノロジースタックを体系的に定義でき、チーム全体の技術理解を統一できます。 既存アーキテクチャがある場合はそれを優先しながら、ガイドとテンプレートで更新・補足が効率的に進みます。 テンプレートとガイドに従うだけで、プロジェクト固有のベストプラクティスに則った設計書が完成します。 システムアーキテクチャを一から設計・定義する必要があるエンジニアやテックリード 既存のアーキテクチャ設計書をメンテナンス・更新したいチーム 機能要件から技術的な実装方針に落とし込むプロセスを体系化したい開発チーム アーキテクチャドキュメントの品質・一貫性を保ちたいプロジェクト管理者 このスキルは docs/architecture.md に保存するアーキテクチャ設計書を作成するための詳細ガイドです。設計前に docs/product-requirements.md（PRD）と docs/functional-design.md（機能設計書）を確認します。既存の docs/architecture.md がある場合はそれを最優先とし、このスキルのガイドは参考資料として扱います。新規作成時はこのスキルのテンプレート（./template.md）とガイド（./guide.md）を参照しながら設計書を作成します。既存設計の更新時も、プロジェクト固有の技術選定と設計の構造を維持しながら更新することが重要です。

実装完了をIssueに記録 — コミット情報・変更ファイル・品質チェック結果を自動で収集し、実装サマリとしてIssueにコメント追加 品質チェック結果をドキュメント化 — pytest・ruff・mypyの実行結果を自動で取得し、チェック通過を明記 関連ドキュメントを自動リンク — ステアリングファイル（設計・要件・タスクリスト）への参照を自動で含める Issueを自動クローズ — 上記のコメント追加と同時にIssueを完了状態で閉じる プロジェクト管理者 — 実装完了の報告作業を自動化し、Issue管理の手間を削減したい人 開発チーム — 実装後の定型的なIssue更新作業をスキップしたい開発者 品質管理担当者 — 品質チェック結果を一元的に記録し、プロジェクトの品質トレーサビリティ（追跡可能性）を確保したい人 実装完了後のタイミングで使用：コード実装とテスト完了後、pytest/ruff/mypyなどの品質チェックが全てパス、git commit/pushが完了した状態。前提条件として、ghコマンドのインストール、ステアリングファイル（.steering/[日付]-[タスク名]/）の作成が必要。基本的な使用方法は /close-issue で実行。スキルが自動的に行うことは以下4点：(1)最新のコミット情報を取得（ハッシュ・メッセージ・変更ファイル）、(2)実装サマリを生成（変更内容・ファイルリスト・品質チェック結果）、(3)Issueにコメントを追加（実装完了報告・詳細・品質保証結果・ドキュメントリンク）、(4)Issueをクローズ。実装手順は以下5つのステップで構成：引数確認→最新コミット情報取得→ステアリングファイル確認→品質チェック結果取得→Issueの更新（ghコマンドでコメント追加・クローズ）。

プロダクト構想を実装レベルまで詳細化 - アイデアをチームが実装できるレベルの具体的な仕様に落とし込めます。 ユーザーの課題と解決策を明確化 - ターゲットユーザーが直面している問題と、プロダクトがそれをどう解決するかを整理できます。 成功指標を定量的に定義 - 「使いやすい」「高速」といった曖昧な目標を、実測可能な数値に変換できます。 機能の優先度を決定 - MVP（最小限の実行可能なプロダクト）に含める機能と、将来追加する機能を明確に区分できます。 ステークホルダー間の認識を統一 - エンジニア、デザイナー、営業などが共通理解を持つための中心ドキュメントになります。 プロダクトマネージャー - アイデアから実装計画までを体系的に整理したい人 スタートアップ創業者 - MVP定義や投資家へのピッチ資料の基礎を作りたい人 開発チームリード - 曖昧な要件をエンジニアが実装できる具体的なスペックに変えたい人