svelte-mcp-feedback

Svelte MCP フィードバック

ユーザーに修正された間違いを、sveltejs/ai-tools の Svelte MCP オートフィクサー向けの実用的なフィードバックに変換します。

1. オートフィクサーの対象となる問題を特定する

会話と、直前に作業したコードを使って、次の内容を特定します。

• 生成した誤ったコードと、ユーザーによる修正。
• 修正の根拠となる Svelte または SvelteKit のルール。
• MCP が検出できる再利用可能なコードパターンと、提示できる修正または提案。

+page.ts、+layout.server.ts、+server.ts、hooks.server.ts、svelte.config.js などの SvelteKit の JavaScript／TypeScript ファイルも対象に含めます。フィードバックは .svelte ファイルに限りません。

具体的で汎用性のある Svelte／SvelteKit の間違いがある場合にのみ続行します。製品要件の変更、個人的な命名の好み、無関係なアプリケーションのバグは、オートフィクサーの課題として報告する理由になりません。修正内容が曖昧な場合は、ユーザーの作業を続けながら確認してください。

ユーザーの修正を反映して、依頼された作業を完了します。フィードバックの報告によって、元の間違いを未修正のままにしてはいけません。

2. 最小限の再現例を作成する

間違いを再現できる範囲で、修正前／修正後のコードを最小限の例にします。無関係なプロジェクトコード、認証情報、会話履歴をそのままコピーせず、汎用的な名前とサンプルデータを使用します。

Svelte MCP を利用できる場合は、関連ドキュメントを確認し、対応するファイル形式であれば誤った例に対して svelte-autofixer を実行します。問題を見落としたのか、誤った修正を提案したのか、それとも問題をすでに報告していたのに見落とされていたのかを記録します。出力を確認せずに、ツールが見落としたと主張してはいけません。ツールが利用できない場合、またはファイル形式に対応していない場合は、その旨を記載します。それでも新しいルールの提案は有用です。

既存の診断が修正内容を明確に扱っている場合は、新しいルールをリクエストせず、その診断に従います。新たに報告するのは、診断が分かりにくい、誤った修正案を提示する、特定のケースを見落とすなど、具体的な問題に限ります。

次のタイトルと Markdown 本文を用意します。

タイトルの例：Autofixer: detect <incorrect pattern>

本文には次の項目を含めます。

1. Summary — 間違いの内容と、それが重要な理由。
2. Incorrect code — 関連するファイル名／ファイル形式を示した、最小限のコード例を含むフェンス付きコードブロック。
3. User correction / expected code — 修正後のコード例と、その簡単な説明。
4. Proposed detection and fix — 識別可能なパターン、提案する変換またはガイダンス、修正が曖昧になるケース。
5. Current MCP behavior — 実際に関係する出力、または理由を添えた「未確認」という明示。
6. Environment — 判明している場合は、Svelte、SvelteKit、MCP、モデルの各バージョン。分からないバージョンを作り上げないでください。

元のプロジェクトを知らないメンテナーでも、パターンと期待する結果を理解できる内容にします。

3. Issue を作成する

GitHub CLI がインストール済みで、認証済みの場合は使用します。gh --version と gh auth status で確認してください。Issue がユーザーのプロジェクトリポジトリではなく、必ず sveltejs/ai-tools に作成されるよう、常に --repo sveltejs/ai-tools を指定します。

同じパターンの報告がすでにないか検索します。

gh issue list --repo sveltejs/ai-tools --state all --search '<pattern keywords>' --limit 20

該当しそうな Issue は gh issue view <number> --repo sveltejs/ai-tools で確認します。同じ再現例と期待する修正を説明する Issue がすでにある場合は、重複して作成せず、そのリンクを共有します。修正済みとされているクローズ済み Issue があるにもかかわらず、例で問題が再現する場合は、その回帰について説明し、新しい報告から以前の Issue にリンクします。

Issue の本文は、ファイル書き込みツールまたは引用付きヒアドキュメントを使って一時的な Markdown ファイルに書き込みます。タイトルは安全に引用した引数として渡し、コードスニペットやバッククォートがシェルで解釈されないよう --body-file を使います。

gh issue create --repo sveltejs/ai-tools --title 'Autofixer: detect <incorrect pattern>' --body-file '<temporary-body-file>'

作成された Issue の URL を取得し、共有します。ラベルや担当者を推測して指定してはいけません。作成に失敗した場合は、失敗したことを報告し、ブラウザーでの代替手段を使います。結果が不確かな場合（送信後のネットワークタイムアウトなど）は、再試行する前に Issue が作成されていないか確認します。

ブラウザーでのフォールバック

gh が利用できない場合、認証されていない場合、またはイシューを作成できない場合は、次の URL を作成します。

https://github.com/sveltejs/ai-tools/issues/new?title=<encoded-title>&body=<encoded-body>

各クエリ値は encodeURIComponent、URLSearchParams、または同等の URL エンコーダーでエンコードしてください。生の Markdown を URL に直接埋め込まないでください。利用可能なブラウザーツール、またはプラットフォームの URL オープナー（macOS の open、Linux の xdg-open、PowerShell の Start-Process）で URL を開きます。これにより、新規イシューのフォームに下書きが入力された状態で開き、ユーザーが送信できます。

レポート全体を含めると URL が長くなりすぎる場合は、タイトルと短い概要を入力し、貼り付け用の Markdown 本文全体をユーザーに提供します。ブラウザーを開けない場合は、クリック可能な入力済み URL と本文を回答に含めます。

結果を明確に伝えてください。作成済みまたは既存のイシューの URL を提示するか、下書きフォームの準備ができており、ユーザーがまだ送信する必要があることを伝えます。その後、ユーザーの元のタスクに戻ります。