英文の説明をそのまま日本語の説明に変換します。自然な日本語で、一般向けにわかりやすく訳しました。 --- 日本語訳（英文説明）を日本語として自然で分かりやすい文章に訳してください。 平易な英語での説明をもとに、実際に使える繰り返し実行可能なレポートに変換します。対象となる指標を定義し、接続されているあらゆるデータソースから取得し、チャットでの要約とExcelファイル形式のブックを提供し、同じレポートを必要に応じて、または スケジュール通りに再実行できるように定義を保存します。「地域別売上と前年比較」から売掛金の経過月数分析、労働費が売上に占める割合まで、あらゆることに対応します。コネクター（連携機能）が利用できない場合は、アップロード済みのCSVまたはExcelファイルから完全に動作します。 次のような場合に使用： - 所有者がレポート、ダッシュボード（情報の一覧表示画面）、KPI集約データ、指標の要約、または繰り返しの数値データを求めている場合 - 「毎週これを追跡してくれますか」「これらの数値を毎月確認したい」「～についてレポートを作成してほしい」「前回と同じレポート」「KPIダッシュボード（情報の一覧表示画面）を作成してほしい」といった表現を含む場合 所有者が「レポート」という言葉を使わずに指標の名前だけを挙げる場合でも、このスキルの使用を検討してください。
Turns a plain-English description of a recurring report into a real, repeatable report — defines the metrics, pulls them from whatever data sources are connected, delivers a chat summary plus an XLSX workbook, and saves the definition so the same report reruns on demand or on a schedule. Handles anything from "sales by location versus last year" to AR aging to labor as a percentage of revenue. Works fully from an uploaded CSV or XLSX when no connector is available. Use this whenever the owner asks for a report, dashboard, KPI pack, metrics summary, or recurring numbers — including phrasings like "can you track this every week," "I need to see these numbers monthly," "build me a report on," "same report as last time," or "put together a KPI dashboard." Reach for it even when the owner names the metrics without using the word report.
オーナーがレポートを説明するのは一度だけ。あなたがそれを構築し、実行し、定義を保存すれば、二度と説明する必要がなくなります。
現在、オーナーたちは3つのダッシュボードから手作業で数字を引き出し、その意味を自分たちで探ろうとしています。その作業を終わらせることが目標です。
何よりもまず、reference/saved_reports.mdを読んで、そのレポートが既に存在するかを確認します。また、作業フォルダ内にreport-definitions.mdがないかも確認してください。スキルフォルダへの書き込みができない場合、定義はそこに保存されます（ステップ7参照）。
オーナーが「前回と同じレポート」「いつもの週次レポート」と言ったり、既に定義がある名前のレポートを指定したりした場合は、ステップ4にスキップして実行してください。既に定義済みのレポートについて再度聞き取りを行うことほど、このスキルが壊れていると感じさせる方法はありません。
合致するものがなければ続行します。
オーナーはレポートをざっくり説明します：「毎週月曜日に、場所別の売上と去年との比較、売掛金の経過状況、労務費の割合」。この一文には4つの独立した決定が含まれています。これらをreference/report_spec.mdの形式を使って仕様に落とし込みます：
合理的に推測できることは推測します。「場所別の売上と去年との比較」から、指標、グループ分け、比較対象がわかるなら、その点については聞かないでください。本当に曖昧な部分についてだけ、複数質問をまとめて一度に聞きます。
ほぼ毎回聞く価値のある2つの質問：
これらを間違えると、見た目は正しいのに実は間違ったレポートが生まれます。これは質問しないより悪いです。
解決した仕様をコンパクトなブロックで見せ直します。一度の確認を求めたら、構築に進みます。仕様を項目ごとに説明しないでください。オーナーは一文で説明し、一つの答えを期待しています。
修正があれば適用して進みます。二度目の確認はしないでください。
すべてのデータソース呼び出しを1つの並列バッチで実行します。指標とツールのマッピングについてはreference/data_sources.mdを参照してください。
データソース（同時にアクセス）：
../../shared/connector-neutrality.mdに従う。損益計算書の各行、売上、経費、売掛金の経過状況、買掛金、分類・場所の内訳。MYOB は損益計算書、売掛金、買掛金のみで、過去3会計年度分。2つの財務台帳が接続されている場合は、どちが正式記録かを聞き、そちらから合計を取得しますソースがエラーを返すか何も返さない場合は記録して先に進みます。1つの接続ミスでレポート全体をブロックしないでください。
接続されたデータソースが全くない場合も、サポートされた方法です。失敗ではありません。 CSV または XLSX ファイルのエクスポートを求め、それを読み込んで同じレポートを構築します。はっきり言いましょう：「接続されたデータソースが見当たりません。お使いのシステムから売上レポートをエクスポートして、ここにドロップしてください。そのファイルから同じレポートを構築します」と。ツールをたくさん使っている所有者はこのモードで生活していますが、レポートは同じくらい優れています。
仕様に名前が挙がっているすべての指標を計算します。その後、結果を表示する前に確認します。実際に起こる失敗パターンについてはreference/gotchas.mdを読んでください。
実際のエラーを捉える確認事項：
2つの成果物を、この順序で。常にこの順です。
チャットサマリーが最初に来ます。 reference/output_template.mdに従ってください。テーブルのダンプではなく、何が変わり、何を意味するのかで始めます。オーナーはスプレッドシートではなく意思決定のためにレポートを求めました。
文章ルール（このプラグインのすべてのレポートスキルと同じ）：
次に XLSX。 指標グループごとに1つのタブ、サマリータブを最初に、生のデータを最後のタブに配置して、オーナーが計算を確認できるようにします。手作業ではなくスクリプトで構築します。
その後、オーナーの保存された出力設定に従ってレポートページを作成してください。マークダウンファイルをデフォルトにしないでください。 ## Business contextブロックのOutput preferenceを確認してください（共有スタイルガイドのルール、../../shared/artifact-style.md）：
仕様をreference/saved_reports.mdに追記し、作成日と頻度を記載します。これがレポートを1回限りから定期的なものに変えます。
そのファイルに書き込めない場合、スキルフォルダがほとんどのインストール環境で読み取り専用の場合、定義をオーナーの作業フォルダ内のreport-definitions.mdに書き込む代わりに、どこに行ったかを述べてください。保存に失敗したが、これがサイレント失敗した定義は、保存されなかった場合と同じバグです。
オーナーが頻度を指定した場合、1行で確認します：「保存しました。毎月最初の月曜日に実行します」と。スケジューリングはこのスキルのプロパティです。別のコマンドは不要です。
1行：レポートが実行され、定義が保存されました。その後、最も関連性の高い次のステップ、最大で他に2つ：
/report-packを実行し、これをスケジュールに沿った文脈でラップします。business-pulseを実行し、これらの数字の周辺の全体像を得ます。cash-flow-snapshotを実行します。最大3つのオファー。今回のセッションでオーナーが断ったオファーは繰り返さないでください。
saved_reports.mdを毎回最初に確認してください。reference/report_spec.md — 仕様の形式、具体例付きreference/data_sources.md — 指標からコネクタへのマッピング、フォールバック付きreference/output_template.md — チャットサマリーとワークブックの正確な構造reference/saved_reports.md — 保存されたレポート定義、時系列で追記reference/gotchas.md — 確信を持って誤ったレポートを生み出す失敗パターンこのスキルに名前が挙がっているコネクタはテストされたパスであり、壁ではありません。オーナーがこのフローを接続されていないまたはリストにないツールを使うことを望む場合は、build-connectorを提供します。まずコネクタディレクトリを確認し、必要に応じて Zapier 経由で接続します。手作りの生 API には対応しません。接続が存在すれば、そのツールは他のオプショナルコネクタと同じように、同じ承認ゲートの下、このスキルに参加します。
The owner describes a report once. You build it, run it, and save the definition so it never has to be described again.
Owners are pulling numbers out of three dashboards by hand and trying to find the story themselves. The job is to end that.
Before anything else, read reference/saved_reports.md and check whether this report already exists. Also check for a report-definitions.md in the working directory — that's where definitions land when the skill folder isn't writable (see Step 7).
If the owner says "same report as last time," "run the weekly one," or names a report you have a definition for, skip straight to Step 4 and run it. Re-interviewing someone about a report they already defined is the fastest way to make this skill feel broken.
If nothing matches, continue.
Owners describe reports loosely: "every Monday, sales by location versus last year, AR aging, and labor percent." That sentence contains four separate decisions. Resolve them into a spec using the format in reference/report_spec.md:
Infer what you reasonably can. "Sales by location vs last year" gives you the metric, the grouping, and the comparison — don't ask about those. Ask only about what's genuinely ambiguous, and ask it in one batch rather than one question at a time.
The two questions worth asking almost every time:
Getting these wrong produces a report that looks right and is quietly wrong, which is worse than asking.
Show the resolved spec back in a compact block. Ask for one confirmation, then build. Do not walk the owner through the spec field by field — they described this in one sentence and expect one answer.
If they correct something, apply it and go. Do not re-confirm a second time.
Dispatch every source call in a single parallel batch. See reference/data_sources.md for the metric-to-tool mapping.
Sources, tried simultaneously:
../../shared/connector-neutrality.md. P&L lines, revenue, expenses, AR aging, AP, class and location splits. MYOB is P&L, AR, and payables only, three financial years back. If two ledgers are connected, ask which is the source of record and take totals from that oneIf a source errors or returns nothing, record it and move on. Never block the whole report on one bad connector.
No connectors at all is a supported path, not a failure. Ask for a CSV or XLSX export, read it, and build the identical report from the file. Say so plainly: "I don't see a connected data source. Export the sales report from your system and drop it here — I'll build the same report from that." Owners with tool sprawl live in this mode, and the report is just as good.
Compute every metric named in the spec. Then check the results before showing them. Read reference/gotchas.md for the failure modes that actually happen.
The checks that catch real errors:
Two artifacts, always, in this order.
The chat summary comes first. Follow reference/output_template.md. Lead with what changed and what it means, not with a table dump. The owner asked for a report because they want a decision, not a spreadsheet.
Writing rules, same as every reporting skill in this plugin:
Then the XLSX. One tab per metric group, a summary tab first, raw pulled data on a final tab so the owner can check your math. Build it with a script rather than by hand.
Then the report page, per the owner's stored output preference — never default to a markdown file. Check the ## Business context block's Output preference (shared style guide rule, ../../shared/artifact-style.md):
Append the spec to reference/saved_reports.md with the date it was created and the cadence. This is what makes the report recurring instead of one-off.
If that file can't be written — the skill folder is read-only in most installed runtimes — write the definition to report-definitions.md in the owner's working directory instead and say where it went. A definition that silently failed to save is the same bug as never saving it.
If the owner asked for a cadence, confirm it in one line: "Saved. I'll run this the first Monday of each month." Scheduling is a property of this skill — no separate command needed.
One line: the report ran and the definition is saved. Then the single most relevant next step, with at most two others nearby:
/report-pack to wrap this in context on a cadence.business-pulse for the picture around these numbers.cash-flow-snapshot when the report raised a cash question.Max three offers. Never repeat an offer the owner declined this session.
saved_reports.md first, every time.reference/report_spec.md — the spec format, with worked examplesreference/data_sources.md — metric to connector mapping, with fallbacksreference/output_template.md — exact structure for the chat summary and the workbookreference/saved_reports.md — stored report definitions, appended to over timereference/gotchas.md — the failure modes that produce confidently wrong reportsThe connectors named in this skill are the tested paths, not a wall. If the owner wants this flow to use a tool that isn't connected or listed, offer build-connector — it checks the connector directory first and connects through Zapier otherwise, never hand-building against a raw API. Once the connection exists, the tool joins this skill like any other optional connector, under the same approval gates.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。