Skill.md検索

Issue番号のリストを指定するだけで、複数のWorktree（Git作業ツリー）を自動で一括作成し、チーム内で並列開発を効率よく進められます。 各Worktreeが独立した環境として機能するため、異なるブランチで同時に複数の開発タスクを進め、マージコンフリクトのリスクを減らせます。 自動生成されたパスと完了状況を一覧表示し、開発者が次のアクション（各Worktreeでの開発開始）をすぐに実行できるようにサポートします。 エラーが発生しても処理を続行し、一部の失敗で全体プロセスが止まらないようにします。 複数のIssueを同時進行したいエンジニア、特にマイクロサービス開発や複数モジュールの並列開発を行うチーム git worktreeの細かい使い方を毎回調べるのが煩雑なエンジニア Wave計画に基づいて複数の機能開発を効率的にスケジュールしたいプロジェクトマネージャー ローカル環境で複数ブランチを切り替えずに、独立した作業環境を維持したい開発者 本スキルは3つのステップと注意事項で構成されています。ステップ1：スペース区切りで複数のIssue番号を受け取り、各Issue番号をfeature/issue-{番号}形式のブランチに変換します。ステップ2：各Issue番号に対して順番に（並列実行ではなく）/worktreeコマンドを実行します。直接git worktree addは使用せず、必ずSkill経由で呼び出すことで一貫性を保ちます。ステップ3：全Worktreeの作成状況をテーブル形式（Issue・ブランチ・パス・状態）で報告し、開発開始の指示を提供します。注意事項：/worktreeコマンドを必須で使用、順番実行（並列禁止）、エラー時も継続するという3点があります。

チームの作成と管理: TeamCreate ツールでリーダーと複数のチームメイトで構成されたプロトタイプチームを自動作成します。 タスクの登録と依存関係の設定: 複数のタスクを作成し、タスク間の依存関係（「タスクAが完了するまでタスクBは実行しない」）を自動で設定できます。 チームメイトへの自動割り当て: タスクを複数のチームメイトに割り当て、メッセージ送受信で進捗を追跡できます。 ライフサイクルの検証: チームメイトの起動、アイドル状態、シャットダウンの一連の動作を確認できます。 基本パターンの動作確認: API の主要機能（TeamCreate、TaskCreate、TaskUpdate、TaskList、SendMessage）が正しく動作するか検証できます。 Agent Teams API を導入する前に、基本的な動作を確認したい開発チーム チーム協働型のタスク管理システムをテストしたい人 タスク依存関係を含むワークフロー管理が必要なプロジェクトマネージャー Wave 2以降のより複雑な実装に進む前に、基礎を固めたい開発者 このスキルは、Agent Teams API の最小プロトタイプ（リーダー + 2チームメイト）を実行し、基本パターンを検証します。実行は3つのフェーズに分かれます。 Phase 1: チーム作成: TeamCreate ツールで「prototype-team」という名前のチームを作成します。 Phase 2: タスク登録と依存関係設定: (1)「テストデータファイルの生成」（独立タスク）と(2)「テストデータの読み込みと検証」（依存タスク）の2つを TaskCreate で登録し、TaskUpdate の addBlockedBy で task-2 を task-1 に依存させます。TaskList で依存関係が正しく設定されたことを確認します。 Phase 3: チームメイトの起動とタスク割り当て: prototype-worker-a と prototype-worker-b の2つのチームメイトを Task で起動し、それぞれのタスクを割り当てます。worker-a がデータを生成してファイルに書き出し、SendMessage でリーダーに完了通知を送ります。worker-b は task-2 がブロック解除されるまで待機した後、データを読み込んで検証し、完了をマークします。

特定のセクター（例：テクノロジー、ヘルスケア、エネルギー）に対して、セクター概況、競争構造、企業間比較、カタリスト・リスク、銘柄選定の5つの分析ピラーで包括的に分析できます。 市場データ、SEC Filings、業界レポート、専門メディアを自動収集・クロス検証し、セクター内企業の財務指標、バリュエーション、成長性を横断比較できます。 セクター代表 ETF を基準に市場全体の動向をキャッチし、セクターローテーション判断や規制動向・技術変化などのリスク分析を統合したレポートを生成できます。 ICE スコアリングに基づく銘柄推奨や投資テーマ別のトップピック提示により、セクター内での最適な投資先を提案できます。 特定セクターへの投資判断を下す前に、包括的な業界分析が必要な機関投資家やアナリスト セクター内の複数銘柄を比較検討し、最有力候補を絞り込みたいファンドマネージャー セクターローテーション戦略を立てるため、複数セクターの相対評価を必要とするストラテジスト 業界動向、競争環境、規制リスクを統合的に把握したい企業の経営企画・事業開発チーム sector（必須）でセクター名を指定（例：Technology、Healthcare、Financials、Consumer_Discretionary、Energy）。各セクターに代表 ETF が割り当てられている（XLK、XLV、XLF、XLY、XLE）。subsector（任意）でサブセクター指定（例：Semiconductors、Pharmaceuticals、Banks）。companies（任意）でティッカーをカンマ区切り指定（例：NVDA,AMD,INTC,TSM）；省略時は industry-research-presets.json から自動取得。sector_etf（任意）でセクター代表 ETF を明示指定。analysis_period（任意、デフォルト 5y）で分析期間を 1y/3y/5y から選択。output（任意、デフォルト report）で出力形式を report/article/memo から選択。スキルは市場データ・SEC Filings・業界レポート・メディアを WebSearch、WebFetch、Bash ツールで自動収集・クロス検証し、セクター比較分析とレポート生成を一元化。

Markdown ファイルを Word（.docx）形式に自動変換し、游明朝・Times New Roman などの統一されたデザイン（余白1.5cm、本文10.5pt）を適用します。 複雑な図表や矢印・罫線で表現されたASCIIアート（図解）を、自動的に日本語の文章に変換して納品物として使える品質に仕上げます。 表のフォント・行間・罫線を後処理で自動調整し、手動修正を不要にします。 分析レポートや調査結果を Markdown で作成し、顧客・チーム向けに Word で納品したいビジネスアナリストやコンサルタント /dr-stock（株価分析）や /ca-eval（企業評価）など、レポート生成ツールの出力を Word 化して共有したい人 複雑な図解を含むドキュメントを Markdown で書きながら、最終形式は Word で統一したい編集者やドキュメント作成者 Markdown の可読性は保ちながら、フォーマルな見た目の納品物が必要な場面 入力ファイル確認→ASCIIアート検出→（検出時は文章化）→pandoc で reference.docx テンプレート適用→表フォント後処理（9pt に調整）という処理フローです。ASCIIアートが検出された場合、矢印や罫線が示す因果関係・階層関係を「〜は〜と相互補完する」などの自然な日本語文に変換し、一時 Markdown ファイルを作成してから変換します。元の Markdown ファイルは変更せず、テンプレートは游明朝 10.5pt（本文）、Times New Roman（英語）、コードブロック Consolas 9pt、見出し1-3 は 16-12pt Bold で統一されます。

市場データを自動収集・整理 - 株価指数、セクター分析、金利・通貨データをyfinance/FREDから取得し、見やすいJSON形式で集約します。 複数ニュースソースを一元化 - GitHub Project・RSS・Tavily を連携させ、金融ニュース・テック情報・企業決算を自動収集・カテゴリ分類します。 仮説ベースの深掘り分析 - 市場データから検出したパターンを仮説化し、その仮説に基づいた追加ニュース検索を自動実行して根拠を強化します。 完成度の高いレポートを自動投稿 - 作成したレポートを自動検証（文字数・フォーマット・データ整合性）し、基準達成時にGitHub Issueとして自動投稿します。 金融アナリスト - 毎週の市場情報を効率的に収集・整理・分析したい 投資家・トレーダー - 主要な市場動向・セクター分析を短時間で把握したい 投資銀行・運用会社 - 顧客向けレポートのドラフト作成を自動化したい マーケティング部門 - 業界トレンド・競合動向をタイムリーに社内共有したい 週次マーケットレポート自動生成スキルは、3つのモード（基本モード・--weekly-comment・--weekly推奨）で動作します。--date（YYYY-MM-DD）パラメータで指定した日付が終了日となり、自動で7日前が開始日に計算されます。基本モードは単日のレポート生成、--weekly-commentは火曜〜火曜の旧形式（3000字以上）、--weeklyはフル週次レポート（5700字以上、GitHub Project連携・自動Issue投稿）です。処理フローはPhase 1初期化 → Phase 2市場データ収集（indices.json・mag7.json・sectors.json等）→ Phase 3仮説生成（将来計画）→ Phase 4ニュース調査 → Phase 5レポート生成（サブエージェント連携）→ Phase 6品質検証 → Phase 7自動Issue投稿となります。収集ツール（yfinance/FRED経由データ、RSS MCP、Tavily検索、githubコマンド）と複数サブエージェント（market-hypothesis-generator、weekly-data-aggregation、weekly-comment-generation等）により、5700字以上の完成度高いレポートを自動生成できます。

改善前後のメトリクス測定: コード品質スコア、循環的複雑度、パフォーマンススコア、テストカバレッジなど定量的な指標を取得し、改善効果を数値で証明できます。 段階的で安全な改善実装: 関数の分割、命名改善、複雑性削減などの改善を小さな原子的変更として順序立てて実行し、各ステップでテストを実行して回帰がないか確認できます。 複数の改善モードから選択: コード品質・パフォーマンス・アーキテクチャの3つの改善方針から選べるほか、リファクタリング・繰り返し改善・保守的改善などのフラグで改善の激度を調整できます。 改善優先順位の自動判定: パフォーマンスボトルネック、可読性の低さ、DRY 原則違反など、改善による影響度とリスクに基づいて優先順位を自動決定できます。 改善結果のレポート出力: YAML 形式でメトリクス、改善内容、効果を体系的に記録し、後から改善の根拠と成果を追跡できます。 ソフトウェアエンジニア: 「何を改善するべきか」を推測でなく、測定値に基づいて判断したい チームリード: メンバーのコードを定量的に評価し、改善の優先順位をデータドリブンで決めたい リファクタリング担当者: 改善前後でメトリクスがどう変わったか可視化して、改善の成果を立証したい 大規模プロジェクト: 複雑性やパフォーマンスの問題箇所を自動検出し、計画的に改善していきたい このスキルは エビデンスベースの改善 を提供。プロアクティブ使用として、複雑性が高い、可読性が低い、パフォーマンス問題がある、アーキテクチャが不明瞭な場合に自動で検討。プロセスは (1)現状分析（make check-all でメトリクス測定）→ (2)計画立案（影響度高い改善を優先）→ (3)実装（improvement-implementer サブエージェント + quality-checker で検証）→ (4)検証（全テスト実行 + メトリクス再測定）。改善モードは --quality（可読性・保守性・複雑性削減）、--perf（アルゴリズム効率化・メモリ削減・並列化）、--arch（設計パターン適用・依存性注入・モジュール再編成）。実行モードフラグは --refactor（動作保持して構造改善）、--iterate（閾値まで繰り返し）、--safe（保守的のみ）、--metrics（改善前後表示）。品質閾値は --threshold low/medium/high/perfect で段階調整。出力は YAML レポート（デフォルト: src//docs/improve-report-YYYYMMDD.yaml）に保存。allowed-tools は Read/Bash/Task。

Red → Green → Refactor のTDD サイクルに従うことで、失敗するテストを先に書き、最小限の実装で通すため、仕様漏れのない堅牢なコードが完成します。 「test_正常系_有効なデータで処理成功」のような日本語命名規則を使って、テストケースの意図を一目瞭然にし、テスト保守性を大幅に向上させます。 単体テスト・プロパティベーステスト（Hypothesis）・統合テストを使い分け、効率よくテストケースを設計・実装できるため、テスト工数を削減できます。 三角測量（仮実装 → 一般化）の手法を使って、段階的に実装を進められるため、複雑な機能でも迷わず実装できます。 テスト優先度（P0必須 → P3任意）に基づいて、限られた時間の中で最大の品質向上を実現できます。 テスト駆動開発（TDD）を実践したいが、テスト設計の具体的な手順が分からない Python・JavaScript 開発者 テストの命名や構成で迷わず、効率的に良質なテストを書きたい開発チーム プロパティテストやフィクスチャなどの高度なテスト手法を学びたい中級以上の開発者 既存プロジェクトの品質を上げるために、体系的なテスト戦略を導入したいプロジェクトリード TDD サイクルは Red（失敗するテスト1つ記述）→ Green（最小限の実装でテスト通過）→ Refactor（コード整理・テスト通過維持）です。テスト命名規則は test_[正常系|異常系|エッジケース|プロパティ|パラメトライズ]_条件で結果() で、日本語での意図を明確にします。テスト種別とファイル配置は、単体テスト（関数・クラス基本動作・tests/unit/test_{module}.py）、プロパティテスト（不変条件・数学的性質・Hypothesis使用・tests/property/test_{module}_property.py）、統合テスト（コンポーネント連携・tests/integration/test_{module}_integration.py）の3種別です。プロパティテストが有効なケースは冪等性・可逆性・不変条件・結合則などです。テスト優先度は P0（主要な正常系・クリティカルエラー）、P1（副次的正常系・一般的エラー）、P2（エッジケース・プロパティテスト推奨）、P3（稀なケース・パフォーマンステスト任意）です。context7 MCP ツールで pytest・Hypothesis・unittest.mock・pytest-asyncio などの最新ドキュメント参照が必須です。

集約データ（aggregated_data.json）と生成コメント（comments.json）から、読みやすい週次マーケットレポートを自動生成できます。 主要指数・MAG7・セクター分析などのテーブルを自動で構成し、Markdown形式で整形できます。 ハイライト・マクロ経済・投資テーマなど複数セクションのコメントを指定位置に自動埋め込みできます。 生成されたレポートをMarkdown形式とJSON形式の両方で出力でき、そのまま公開・配信できます。 マーケットリサーチャー：毎週のレポート作成時間を短縮したい方 投資情報配信者：テンプレート化された一貫性あるレポートを定期配信したい方 アナリスト：データとコメントの組み合わせを自動化したい方 weekly-report-writerエージェントの後工程を担当する方 weekly-template-renderingスキルは、weekly-report-writerエージェント第3フェーズとして、aggregated_data.jsonとcomments.jsonを読み込んでMarkdown形式のレポートを生成します。テンプレートのプレースホルダー（{{report_date}}・{{highlight_comment}}・{{indices_table}}・{{mag7_table}}・{{sectors_top_table}}等）を対応データで置換します。メタデータはreport_date・period.start・period.end・生成時刻JST形式で、コメントはhighlight・indices・mag7・sectors_top・sectors_bottom・macro・themesセクションから引き取ります。出力はarticles/weekly_report/{date}/02_edit/配下にweekly_report.md（Markdown）とweekly_report.json（構造化）として生成され、投資助言ではない旨の免責事項を含めます。

新しいスキル（ナレッジベース）の設計から実装まで、一連のプロセスをサポートできます。スキルが何をするべきか、どんな構造にするかを、ベストプラクティスに基づいて提案します。 既存スキルの品質を評価し、内容の不完全さ、使いやすさの問題、フロントマター設定の誤りなどを改善する具体案を提供できます。 複数のスキルを組み合わせたワークフロー設計や、新しい専門領域に対応したスキルシステムの拡張を手助けできます。 Claude Code の公式仕様に基づくフロントマター（メタデータ）の正しい設定を検証し、スキルが適切にプリロード・参照されるよう整備できます。 スキルの「知識・手順・テンプレート」と実処理（ツール）の役割分担を明確にし、メンテナンス性の高いスキルを作成できます。 チーム内で再利用可能なナレッジやプロセスをスキルとして体系化したい技術リーダー 複数のエージェントで使える共有知識を設計・管理する立場の人 既存スキルの品質向上やスキルシステムの最適化に取り組みたい組織 Claude Code プラットフォームを使ったスキル開発に詳しくなりたい開発者 このスキルは、Claude Code スキルの設計・最適化・レビューを専門とするエキスパートです。プロアクティブに使用する場面は「スキル設計の議論」「スキル品質の問題」「スキルシステムの拡張」です。スキル設計の4つの原則は：(1)スキルはナレッジベース（知識・手順・テンプレート）を提供し、実処理は既存ツール（MCPサーバー、gh CLI、Read/Write/Glob等）を活用する、(2)各スキルは1つの明確なドメイン（例：Pythonコーディング規約、TDD開発プロセス）に特化する、(3)全スキルは標準構造（SKILL.md、guide.md、template.md、examples/）に従う、(4)コンテキスト効率化のためSKILL.mdはクイックリファレンスに、詳細はguide.mdに、具体例はexamples/に分ける。スキルはリポジトリ管理、コーディング、メタスキルの3カテゴリに分類され、各カテゴリに複数のスキル例が示されています。

新しいエージェントの専門的な設計: 特定のドメインや目的に特化したClaude Codeエージェントを、ベストプラクティスに基づいて一から設計・作成できます。 既存エージェントのパフォーマンス改善: 不安定な動作や不明確な責任範囲を改善し、品質と効率性を向上させます。 エージェント品質の包括的なレビュー: 設計、プロンプト工学、ドメインモデル、セキュリティ面から検査し、ベストプラクティスへの準拠を確認できます。 エージェント間の責任範囲を明確化: 複数エージェント間の役割分担を整理し、システム全体の一貫性を保証します。 新しいドメイン固有のエージェント導入を検討している開発者: 設計段階から専門家のサポートで、実用的で保守性の高いエージェントが実現できます。 既存エージェントの動作が不安定または予測不可能: 要件の明確化と設計の見直しで、安定性と信頼性を取り戻せます。 Claude Codeエージェントシステムの全体設計を行うアーキテクト: エージェント間の調整や統合の課題を、体系的に解決できます。 Claudeのエージェント設計パターンやプロンプト工学を学びたい開発者: 実践的なアドバイスと具体例を通じてベストプラクティスを習得できます。 用途: 新規エージェント作成、既存エージェント改善、品質レビューに対応。 プロアクティブ使用: エージェント設計議論、品質問題の検出、システム拡張時に自動で起動検討。 プロセス: ①.claude/agents/の既存エージェント確認でドメイン境界と責任範囲を明確化②AskUserQuestionでエージェント名、専門性、ツール、使用シナリオを確認③標準構造（フロントマター+目的+トリガー条件+プロセス+例+ガイドライン）で実装④バリデーション：fron tmatterのname（kebab-case）、description（トリガーキーワード含む）、color（必須）、参照スキル・ツールの存在確認。既存エージェント改善時は、AskUserQuestionによる徹底的な情報収集が必須。

コマンド・スキル・エージェント一覧を自動検出: ファイルシステムを走査して、現在のプロジェクトに登録されている全コマンド・スキル・エージェントの最新一覧を自動生成します。 ディレクトリ構成を可視化・更新: プロジェクトのフォルダ階層を自動スキャンし、README.mdやCLAUDE.mdの「ディレクトリ構成」セクションを常に最新状態に保ちます。 依存関係図をMermaid形式で自動作成: コマンド→スキル→エージェント、Pythonパッケージ間の依存関係をグラフとして検出し、可視化します。 パッケージREADMEを一括更新: financeやmarket_analysisなど、各パッケージ配下のREADME.mdを並列で自動更新できます。 リファレンス情報を即座に表示: /index コマンドで現在のコマンド・スキル・エージェント一覧をMarkdown形式で表示できます。 プロジェクトリーダー: 新しいコマンドやスキルを追加した際、ドキュメントを手動で更新する手間を削減したい人 チーム全体: プロジェクト構造が最新状態に保たれているかを定期的に確認したい人 ディレクトリ構造を整理中: パッケージ再構成時に、依存関係と構成の整合性を確認したい人 ドキュメント管理担当: README.md、CLAUDE.md、パッケージごとのREADMEを一括メンテナンスしたい人 表示と更新の2つのモード: /index でリファレンスを表示、/index --update で自動検出と更新を実行します。更新モードでは、5つのサブエージェントを並列起動して、コマンド検出（.claude/commands/*.md）、スキル検出（.claude/skills/*/SKILL.md）、エージェント読み込み（.claude/agents.md）、ディレクトリスキャン（プロジェクトルート4層まで）、依存関係検出（コマンド→スキル→エージェント、Pythonパッケージ間）を行います。その後、finance・market_analysis・rss・factor・strategyの各パッケージREADME更新を並列実行し、最終的に .claude/commands/index.md、CLAUDE.md、README.md の該当マーカー（DIRECTORY、DEPENDENCY）セクションを一括更新します。

メインブランチから新しいworktreeを自動作成し、独立した開発環境を即座に用意できます。 ブランチ名を自動判定し、feature/、fix/、refactor/などの適切なプレフィックスを付けて整理できます。 複数の機能開発を同時進行でき、ブランチ間の干渉を避けて並列開発できます。 既存ブランチ、未コミット変更、同名worktreeなどの状態を事前チェックし、安全にworktreeを作成できます。 引数なしで実行時は対話的にヒアリングし、ユーザーの意図に合わせた環境を準備できます。 複数機能を同時に開発・並列管理したいエンジニア worktreeの作成フローを自動化して時間を短縮したい開発者 ブランチ管理を体系的に行いたいチーム /worktreeコマンドで開発環境をワンコマンドで整備したい方 Worktree作成スキルは、新規開発時にメインブランチから派生したworktreeとブランチを自動作成します。ステップ0で引数から機能名を取得し、引数なしならヒアリング（feature/fix/refactor/docs/test/release から選択）します。ステップ1で事前チェック（gitリポジトリ確認、メインブランチ特定、未コミット変更検出、既存ブランチ・worktree確認）を実施します。ステップ2でworktreeパス決定（親ディレクトリの.worktrees/リポジトリ名/ブランチ名に作成）、ステップ3でgit worktree add -b ブランチ名 パスでworktree作成および新規ブランチを生成します。既存ブランチがある場合はworktreeのみ作成し、同名worktreeが存在する場合は警告を表示して処理を中断します。

コンフリクトファイルの自動検出と分類: マージ時に発生したすべてのコンフリクトを自動で抽出し、同一行変更、隣接行変更、削除競合などのタイプに分類します。 問題点とリスク評価の詳細表示: コンフリクトの重要度やマージへのリスクレベルを判定し、対応の優先順位を明確にします。 ステップバイステップの解決手順を提示: ベストプラクティスに基づいた具体的な解決手順とコード例を提供し、安全に競合を解決できます。 自動解決可能なコンフリクト（マージ戦略）の識別: 自動マージ可能な競合を判定し、手動対応が必要な箇所を絞り込めます。 複数の開発者で並行開発をしているチーム: 頻繁にコンフリクトが発生する際の解決時間を短縮できます。 長期間分岐していたfeatureブランチをマージする際: 大規模なコンフリクトの全体像を把握し、効率的に対応できます。 GitHubでマージボタンが無効化されているPR: コンフリクト原因を素早く特定し、解決方法を実行できます。 コンフリクト解決のベストプラクティスを学びたい開発者: リスク評価と手順を参考にしながら、安全なマージを進められます。 役割: このスキルはPRマージ実行（/merge-pr）と詳細レビュー（/review-pr）を分離し、コンフリクトの詳細分析に特化しています。 実行方法: /analyze-conflicts [options] または /analyze-conflicts --local [options] で実行。オプションとして --verbose/-v（詳細コード表示）、--local （ローカルブランチ分析）が利用可能。 プロセス概要: ①PR/ブランチ情報を取得し、コンフリクト有無を確認 ②GitHub APIでコンフリクトファイルを特定（PRモード）またはローカルでシミュレート ③各ファイルのコンフリクトマーカーを抽出・分析 ④同一行変更、隣接行変更、追加競合、削除競合のいずれかに分類 ⑤リスク評価と解決策を提示。ツールはRead、Bashのみで実装。

プロジェクトファイルとインタビュー情報から、高品質なライブラリ要求定義書（LRD）を作成できます。 機能要件をAPI仕様レベルまで詳細化し、成功指標を測定可能な形で定義できます。 生成したLRDを４つのレビュー観点（目的・利用者・成功指標・機能詳細度・非機能要件）でチェックし、改善が必要な箇所を明識できます。 新規ライブラリ開発を立案しており、要件を体系的に整理したい開発リード・アーキテクト プロジェクト企画・PM で、ライブラリの目的や成功指標を明確に定義したい方 チーム全体で開発要件を共有し、実装の方向性をそろえたい組織 LRD作成は /new-project コマンドから呼び出され、プロジェクトファイル（src//docs/project.md）の内容とインタビュー結果がコンテキストに含まれます。既存のLRD（src//docs/library-requirements.md）がある場合はそれを最優先し、ガイドはあくまで参考資料とします。作成プロセスは(1)プロジェクトファイルの確認、(2)テンプレートに従ったLRDドラフトの生成、(3)５つのレビュー観点でのチェック（目的の明確性・利用者の具体性・成功指標の測定可能性・機能要件の詳細度・非機能要件の網羅性）、(4)改善点の一つずつの確認と修正を繰り返します。すべての要件は具体的で測定可能であること、利用者中心設計に基づくことが重要です。出力先は src//docs/library-requirements.md です。

graph-queue JSON形式のデータを読み込み、Neo4jデータベースに自動投入できます（MERGE演算子で重複を防止） Entity、Claim、Fact、Topic、Author など14種類のノードを冪等（べきとう）に投入できます リレーション（関係性）も31種類自動生成され、ノード間の複雑な関連性を自動で接続できます 複数ファイルから段階的にデータを投入し、途中失敗時も安全に再開できます 処理内容を事前確認する「ドライラン」モード、処理済みファイルの保持オプションなど、細かい制御が可能です Knowledge Graph（知識グラフ）を構築・管理しているデータエンジニア 複数のデータソースから抽出した情報をグラフDBに統合したい分析者 Neo4j運用で、冪等性を保ちながら安全にデータ投入したい技術者 AI/RAGシステムの基盤となるナレッジベースを構築している開発チーム このスキルは4フェーズ構成で動作します。Phase 1（キュー検出・検証）では、Neo4j接続確認後、.tmp/graph-queue/配下の未処理gq-*.jsonを検出し、JSON スキーマ検証（schema_version、queue_id、created_at等の必須キー確認）を実施します。Phase 2では14種ノードをトポロジカルソートで投入（Topic→Entity→FiscalPeriod→Source→Author→Fact→Claim→FinancialDataPoint→Insight→Method→Anomaly→PerformanceEvidence→MarketRegime→DataRequirement）。Phase 3aでファイル内リレーション（TAGGED、MAKES_CLAIM、ABOUT等）をMERGE実行、Phase 3bでクロスファイルリレーション（既存ノードとの関連付け）を投入します。Phase 4で処理完了処理と統計出力を実行します。引数は--source（コマンドソース指定）、--dry-run（実行なしで確認）、--skip-cross-link（Phase 3bスキップ）、--file（単一ファイル指定）、--keep（処理済みファイル保持）に対応。

ライブラリ固有の構造を設計 - ライブラリの特性（再利用可能性、API設計、依存関係）に最適なフォルダ配置を自動で定義します。 拡張に耐える基盤を構築 - 今後のモジュール追加・API拡張時も対応できる柔軟な構造を事前に設計します。 既存ライブラリ構造を保護 - すでに定義されているディレクトリレイアウトを自動認識し、矛盾なく改善できます。 技術選択に応じた最適配置 - 選定された言語・フレームワーク・パッケージマネージャに合わせた構造を実装します。 ライブラリ開発者 - 再利用可能なパッケージの構造を体系的に設計したい OSS メンテナー - 複数のコントリビューターが理解しやすい構造を定義したい エンタープライズ開発チーム - 社内共有ライブラリの標準化された構造を築きたい 技術リード - src//docs/ 配下の要件書・設計書と連動した構造を自動生成したい このスキルは、ライブラリ開発時の構造定義ガイドです。必須ドキュメント（LRD・機能設計書・アーキテクチャ設計書）をsrc//docs/から読み込み、それに基づいて最適なディレクトリ構造を設計します。既存のsrc//docs/repository-structure.mdがある場合は最優先して尊重します。新規作成時はテンプレート（./template.md）を参照し、出力先はsrc//docs/repository-structure.mdです。`は/new-project`コマンドの引数から自動抽出される仕様により、プロジェクト固有の構造定義を効率的に生成できます。

複雑な要件定義や機能仕様を、1-2時間で完了できる実装可能なタスクに自動分解できます タスク間の依存関係（明示的・暗黙的・ブロッキング）を特定し、Mermaid グラフで可視化できます 循環依存や設計上の問題を検出し、最適な実装順序を提案できます 新規タスクと既存 Issue の類似性を自動判定し、重複 Issue の作成を防止できます 並行開発計画（worktrees など）やプロジェクト管理ツールへの連携が容易になります LRD（Low-level Requirements）から Issue を効率よく生成したい PM・スクラムマスター タスク間の依存関係を把握して並行開発を最適化したい開発リーダー 既存の Issue 管理を整理し、重複や粒度の問題を解決したい組織 アジャイル開発で見積もりや計画を精度を高めたい開発チーム タスク分解の基準：「1-2 時間で完了できるサイズ」、単一責任、独立してテスト可能、見積もり可能、依存明確。依存関係は 3 種類に分類：(1)明示的依存＝直接参照、(2)暗黙的依存＝データフロー・処理順序、(3)ブロッキング依存＝先行必須。プロセス 6 ステップ：(1)要件分析（gh issue list、project.md 確認）、(2)タスク分解実行（単一責任・テスト可能・見積もり可能基準で）、(3)依存関係解析（入出力特定、データフロー追跡、参照抽出、循環依存チェック）、(4)類似タスク判定（高類似 70%+ は既存 sub-issue、中 40-70% はユーザー確認、低 40% 未満は新規作成）、(5)Mermaid 可視化（graph TD 形式）、(6)検証（全タスク独立性・依存関係の正確性・見積もり妥当性）。allowed-tools：Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion, Task。

Python 3.12+ の最新型ヒント（PEP 695）を使った安全で可読性の高いコード実装ができるようになります。 変数・関数・クラス・定数の命名規則を統一し、チーム全体で一貫性のあるコードを書けるようになります。 NumPy形式のDocstring（パラメータ・戻り値・例外・使用例を明確に記述）を標準化し、ドキュメント品質が向上します。 ユーザーの解決策を含む具体的なエラーメッセージを実装し、デバッグ効率が劇的に向上します。 構造化ログの実装パターンを採用し、本番環境でのトラブルシューティングが容易になります。 Python開発チームのコード品質を統一化したいテックリード・アーキテクト Python 3.12+ の新しい型ヒント構文（PEP 695）を導入したい開発チーム コードレビュー時に形式的な指摘を減らし、設計検討に集中したい組織 保守性・可読性の高いPythonコードを継続的に書きたい個人開発者 Python コーディング規約スキルはPython 3.12+向けに型ヒント（PEP 695）、命名規則、Docstring、エラーメッセージ、ロギングの実装パターンを提供します。型ヒント（PEP 695新構文）では組み込み型直接使用（list[str]）、ジェネリック関数（type parameters形式）、ParamSpec（デコレータ用）、境界付き型パラメータを具体例で示します。命名規則は変数（snake_case・名詞）、Boolean（is_/has_/should_/can_）、関数（snake_case・動詞）、クラス（PascalCase・名詞）、定数（UPPER_SNAKE）、ファイル（snake_case.py）、プライベート（_prefix）で統一。Docstring（NumPy形式）はParameters/Returns/Raises/Examplesセクションで記述。エラーメッセージは具体的な値と解決策を含める。プロアクティブ使用は Python コード実装時、コードレビュー時、リファクタリング時に自動参照。

エラー設計パターンの提供: シンプルな例外定義からリッチな例外設計まで、プロジェクトの規模に応じた適切なパターンを選択できます。 例外階層の自動設計: ドメイン固有の例外クラスを体系的に設計し、エラー分類を整理できます。 リトライ戦略の実装: 指数バックオフやフォールバックなどの実装パターンで、外部API連携の堅牢性を向上させます。 ロギングとの統合: structlogなどのロギングフレームワークとの連携パターンで、デバッグ情報の可視性を高めます。 外部API連携を多く扱うバックエンド開発者 エラーハンドリングの設計を体系化したいチーム REST APIサーバーの堅牢性を高めたい開発者 例外クラスの設計について迷っている初心者エンジニア

自然言語からGitHub Issue を素早く作成：「〜の機能を追加したい」というアイデアを説明するだけで、タイトル・説明文・ラベル・優先度が整ったIssueを自動生成できます。 大きなタスクを実装可能なサイズに自動分解：複雑な要件を複数の小さなIssueに分割し、チームが段階的に進められるようにできます。 既存Issueとの重複をチェック：新しく作成しようとしているタスクが既に存在していないか、AIが類似度を判定して教えてくれます。 プロジェクト計画書とGitHub Issuesを同期：project.md（プロジェクト計画）に記載されたタスクを自動的にGitHub Issue化し、チーム全体で進捗管理できます。 プロジェクト・スクラム責任者：タスク管理の手作業を削減し、チーム全体の進捗把握を効率化したい方 開発チームリード：大きな要件を実装可能なサイズに分割するプロセスを自動化したい方 スタートアップ開発者：タスク管理ツール（JIRA等）がない環境で GitHub Issues を活用したい方 フルスタック起業家：開発と企画の両面を自分で進める中で、タスク漏れを防ぎたい方