mcpField
F
fix-reporter

fix-reporter

github.com/majesticlabs-dev開発5061 回インストール7 週間前に更新
リポジトリ

fix-reporter について

解決した技術的な問題を、YAML メタデータ付きの検索可能な Markdown の教訓として記録するスキルです。背景の収集、重複確認、スキーマ検証、関連問題のリンクを案内します。

主な機能

  1. 01症状と根本原因の記録
  2. 02既存の教訓ファイルの検索
  3. 03分類に沿ったファイル名の生成
  4. 04YAML メタデータの検証
  5. 05関連問題の相互参照

活用シーン

  1. 01難しいデバッグ解決策の記録
  2. 02今後のセッション向けの修正保存
  3. 03問題文書の重複回避
  4. 04繰り返す技術課題の把握

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/majesticlabs-dev/majestic-marketplace --skill fix-reporter

インストール後、Claude Code で/fix-reporterを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

schema.yaml
assets/
critical-pattern-template.md
resolution-template.md
references/
yaml-schema.md

詳細

fix-reporter スキル

目的： 解決した問題を記録し、検索可能な組織ナレッジを構築します。

構成： .agents/lessons/[category]/[filename].md に問題ごとに1つのファイルを作成し、YAML フロントマターを付けます。workflow_phase フィールドを含むファイルは、lessons-discoverer エージェントから検索できます。

7 ステップの記録プロセス

ステップ 1：解決の確認を検出する

自動実行のトリガー：

  • 「うまくいきました」、「修正されました」、「動くようになりました」、「問題が解決しました」、「それでできました」

手動実行： /report-fix コマンド

記録するケース：

  • 複数回の調査が必要だった
  • 時間のかかった、難しいデバッグ
  • 一見して分からない解決策
  • 今後のセッションで役立つ内容

記録不要のケース： 単純なタイプミス、明白な構文エラー、些細な修正

ステップ 2：コンテキストを収集する

会話から次の情報を抽出します。

フィールド情報源
モジュール名問題が発生したプロジェクトのモジュール
症状観測できるエラーや動作（正確なメッセージ）
調査で試したことうまくいかなかったこととその理由
根本原因技術的な説明
解決策問題を解決したコードや設定の変更
再発防止今後、同じ問題を避ける方法

重要なコンテキストが不足している場合： ユーザーに質問し、ステップ 3 に進む前に回答を待ちます。

ステップ 3：既存のドキュメントを確認する
# Search for similar issues
grep -r "exact error phrase" .agents/lessons/
ls .agents/lessons/[category]/

類似する記録が見つかった場合： 次の選択肢を提示します。

  1. 相互参照を含む新しいドキュメントを作成する（推奨）
  2. 既存のドキュメントを更新する（根本原因が同じ場合のみ）
  3. その他

見つからなかった場合： ステップ 4 に進みます。

ステップ 4：ファイル名を生成する

形式：[sanitized-symptom]-[module]-[YYYYMMDD].md

ルール：

  • 小文字を使用し、スペースはハイフンにする
  • 特殊文字を削除する
  • 80 文字未満に切り詰める

例：

  • missing-import-auth-module-20251110.md
  • n-plus-one-user-queries-UserService-20251110.md
ステップ 5：YAML スキーマを検証する

schema.yaml と references/yaml-schema.md に照らして検証します。

必須フィールド：

  • module、date、problem_type、component
  • symptoms（1～5 件の配列）、root_cause
  • resolution_type、severity

検証に失敗した場合は処理を中断します — エラーを表示し、修正を求めます。

ステップ 6：ドキュメントを作成する
CATEGORY="[mapped from problem_type]"
mkdir -p .agents/lessons/${CATEGORY}

次の内容を使って assets/resolution-template.md に記入します。

  • ステップ 2 で収集したコンテキスト
  • ステップ 5 で検証した YAML

任意の検索用フィールド： レッスンを自動表示する必要がある場合は、workflow_phase、tech_stack、lesson_type、impact、keywords を追加します。

ステップ 7：相互参照を追加する

ステップ 3 で類似する問題が見つかった場合：

  • 両方のドキュメントに「関連する問題」へのリンクを追加します

類似する問題が 3 件以上ある場合：

  • .agents/lessons/patterns/common-solutions.md への追加を検討します

severity=critical で、解決策が一見して分からない場合：

  • 出力に「クリティカルパターンへの追加を検討してください」と記載します

出力

記録後、fix-decision-router スキルを次の内容で実行します。

doc_path: .agents/lessons/[category]/[filename].md
category: [problem_type category]

カテゴリの対応表

problem_typeディレクトリ
build_errorbuild-errors/
test_failuretest-failures/
runtime_errorruntime-errors/
performance_issueperformance-issues/
database_issuedatabase-issues/
security_issuesecurity-issues/
ui_bugui-bugs/
integration_issueintegration-issues/
logic_errorlogic-errors/
developer_experiencedeveloper-experience/
workflow_issueworkflow-issues/
best_practicebest-practices/
documentation_gapdocumentation-gaps/

成功基準

  • YAML フロントマターが検証済み
  • .agents/lessons/[category]/ にファイルを作成済み
  • 列挙値がスキーマと完全に一致
  • コード例を含む
  • 関連する問題が見つかった場合は相互参照を追加済み
  • fix-decision-router を実行済み

エラー処理

エラー対応
コンテキスト不足ユーザーに質問し、回答を待つ
YAML の検証失敗エラーを表示し、正しい値になるまで処理を中断する
類似する問題の判断が曖昧選択肢を提示し、ユーザーに選んでもらう

品質ガイドライン

含める項目：

  • エラーメッセージの正確な文面（コピー＆ペースト）
  • ファイル名と行番号の参照
  • 観察可能な症状
  • 失敗した試行の記録
  • 技術的な「理由」の説明
  • コード例（変更前／変更後）
  • 予防策のガイダンス

避ける項目：

  • 曖昧な説明
  • 技術的な詳細の不足
  • コンテキストの欠如（バージョン、ファイル）
  • 説明のないコードの羅列

コメント

Markdown 対応