Skill.md検索

機能実装前に失敗するテストを先に作成（Red）し、実装（Green）、改善（Refactor）という3段階で確実に品質を保証します。 バグ報告時に再現テストを最初に書くことで、バグの原因を正確に特定し、修正後に同じバグが再発するのを防げます。 テストファイルとコード実装ファイルが1対1で対応（test_auth.py ↔ src/auth.py）するため、テストの保守性が向上します。 Red-Green-Refactorサイクルを強制することで、チーム全体のテスト駆動開発（TDD）文化が定着し、コード品質が向上します。 ユーザーがテストケースを承認してから実装を開始するため、実装意図の相違がなくなり、修正ループが減少します。 テスト駆動開発（TDD）を導入したい開発チーム バグの再発を減らしたい品質管理者 コード品質と開発効率の両立を目指す開発リーダー 大規模プロジェクトで予測可能な開発進捗を実現したい組織 TDDサイクルは3フェーズです。Red（テスト作成）：tests/test_.pyを作成、期待する動作を明確に定義、エッジケース検討、pytest実行で失敗確認、ユーザー承認取得。Green（最小実装）：テスト通過させるのみに集中、過剰な設計を避ける、pytest実行で成功確認、ruff check --fix/ruff format/mypy実行。Refactor（改善）：テスト保持しながらコード改善、重複除去・可読性向上・最適化、pytest再実行、全テスト確認。テストファイル対応はsrc/auth.py→tests/test_auth.pyで、テストクラスはTestLogin/TestLogoutのように機能単位で組織し、テストメソッドはtest___命名で、テストコードはAAA（Arrange/Act/Assert）パターンを使用します。

Linter（ruff）でコードスタイルやセキュリティ問題を自動検出し、未使用のインポート削除などの自動修正を実行できます。 Formatter（ruff format）でコード行の長さ、インデント、クォートなどを統一し、チーム全体で一貫したコード見た目を保ちます。 型チェッカー（mypy）で関数の引数と戻り値に型アノテーション（str、intなど）がついているかを確認し、型の不整合エラーを事前に発見します。 コミット前やPR作成前に品質ゲート（自動チェック）が実行され、基準を満たさないコードのコミットを防ぎます。 チーム開発でコード品質の一貫性を保ちたい人 型安全性が重要なプロジェクトに携わっている開発者 コード品質問題をレビュー時点ではなく、開発時点で発見・修正したい人 自動修正ツールで機械的な修正を任せたいと考えている人 Constitution Article 5: Code Quality Standards を強制し、コード品質基準の完全遵守を保証します。起動条件はコミット前の最終チェック、PR作成前、品質問題検出時、明示的な品質チェック依頼時です。品質チェック項目は3つ：(1)Ruff Linter（uv run ruff check）で未使用インポート・変数・セキュリティ問題検出、自動修正は --fix オプション。(2)Ruff Formatter（uv run ruff format）でインデント・行長・空白・クォート統一、チェックは --check オプション。(3)Mypy Type Checker（uv run mypy）で型アノテーション確認、型整合性、Any型過剰使用、Noneチェック検証。実行プロセスはQuick Check（高速）、Full Check with Auto-fix（自動修正付き）、Step-by-Step（段階的）から選択可能です。PASS条件は全チェックエラーなし、FAIL条件はいずれかでエラー発生。エラー対応として、Ruffエラーは自動修正またはエラーコード参照、Format エラーは自動フォーマット、Mypy エラーは型アノテーション追加・Optional型追加・Noneチェック追加で対応します。

ブランチ名から自動的にissue番号を抽出し、実装計画・新たな知見・問題発覚などを関連するGitHub issueに構造化されたコメントとして投稿できます。 「feat/121-xxx」「fix/456-xxx」などの標準ブランチ命名規則に対応し、レガシーパターン（「feature/111-xxx」「bugfix/456-xxx」など）もサポートしています。 計画立案時は実装ステップと予想される課題を、知見獲得時はプロジェクトへの影響と推奨アクションを、問題発覚時は再現手順と暫定・根本対応案を自動フォーマットして記録できます。 作業の進捗、判断、課題がissueスレッドに自動蓄積され、ドメイン知識の属人化を防ぎ、プロジェクト全体で知見を共有できます。 複数の機能・タスクに並行して取り組むエンジニアが、進捗をissueに記録したい チームリーダーが各メンバーの判断・課題をissueスレッドで可視化・共有したい プロジェクトドキュメント化の負担を減らしたい ブランチ単位での作業記録を自動的に整理したい ブランチ名抽出＋自動コメント投稿の自動化フロー： Bashコマンドで現在のブランチ名を取得し、正規表現 (feat|fix|chore|docs|refactor|test|feature|bugfix)/{issue-number}-* で issue番号を抽出（先頭ゼロは除去）。gh issue view でissue存在確認後、gh issue comment でコメント投稿。 4種類のコメントテンプレート： 1. 計画立案時（Plan）：「📋 実装計画」セクションに作業概要・ステップ・予想される課題を記載 2. 知見獲得時（Insight）：「💡 新たな知見」セクションに発見内容・詳細・プロジェクトへの影響・推奨アクション（チェックボックス付き）を記載 3. 問題発覚時（Problem）：「⚠️ 問題発覚」セクションに問題概要・詳細・再現手順・暫定対応・根本対応提案を記載 4. その他（Note）：「📝 作業メモ」セクションで記録すべき情報を自由記載 すべてのコメントに投稿日時を自動付加（「Posted by Claude Code at YYYY-MM-DD HH:MM」）。

TOML構文の完全検証: 基本構文・文字列クォート・配列・テーブル・コメント形式をチェックし、構文エラーを自動検出できます。 スキーマ準拠性の確認: 必須フィールド・フィールド型・値の範囲・形式・一意性・整合性を検証できます。 複数設定ファイルの一括検証: team.toml・orchestrator.toml・evaluator.toml・judgment.tomlなど、複数ファイルを同時にチェックできます。 修正方法の自動提案: エラー検出時に具体的な修正内容をユーザーに提案できます。 段階的な検証実行: 特定ファイル指定・ファイルタイプ指定・全設定一括など、柔軟な検証方法を選択できます。 MixSeekプロジェクトの設定管理を担当するエンジニア ワークスペース初期構築時に設定の正確性を確認したい開発者 CI/CDパイプラインで設定エラーを事前に検出したい運用者 チーム開発で設定ファイルの一貫性を保ちたいテックリード 対応ファイル: team.toml(チーム設定)、orchestrator.toml(オーケストレーター設定)、evaluator.toml(評価設定)、judgment.toml(判定設定)。 使用方法: Step 1 検証対象確認(特定ファイルまたは全設定) → Step 2 検証実行(detect-python-command スキルの run-python.sh で validate-config.py 実行) → Step 3 結果報告(成功時は検証項目と結果表示、失敗時はエラー内容と修正方法提案)。 検証項目: TOML構文検証(基本構文・クォート・配列テーブル・コメント) + スキーマ検証(必須フィールド・フィールド型・値範囲・形式・一意性・整合性)。 前提条件: MixSeek-Core/Plus インストール済み、Python 3.13+、uv推奨。成功時は検証済みと表示、失敗時は エラー番号 + 修正手順を番号付きで出力。

コミット、プッシュ、PR作成を1つのコマンドで自動実行し、手作業を削減できます GitHubのデフォルトブランチを自動検出して正しいブランチへプッシュします 品質チェック設定に基づいて、コミット前に自動検証を実行します PRが既に存在する場合は自動で判定し、プッシュのみ実行して二重作成を防ぎます エラー発生時に原因を明確に表示し、次のアクション（認証修正など）がすぐわかります コミット、プッシュ、PR作成の手順を簡略化したい開発者 レビュー依頼を素早く出したいプロジェクト管理者 毎日多くのコード変更を扱うチームリード Gitの細かい操作よりコード品質に集中したい非エンジニア職の技術関連者