Communitygithub.com

Denkos-DS/event-prep

グループイベント(シャレー週末、キャンプ、フェスティバル、パーティー)を計画するためのClaudeスキル。人数計算、掛け算のトラップ、会場の制約をエンコードし、ゲストスケジュール、計画書、コスト計算された買い物リストを生成します。

event-prep とは?

このスキルは、グループイベントの計画における典型的な失敗モード(人数の掛け間違い、調理設備の容量超過、食事情報の不足、予算の誤算など)を体系的に防止するために設計されています。イベント計画はメニューから始めるのではなく、参加者数と食事制限、到着・出発時間、騒音規制、会場の設備(電源、水、調理器具の有無)、サイト数とその距離、既に確定している費用、所有している機材など、7つの重要な要素を安価に確認し、高コストなミスを回避する順序で進める必要があります。特に、予算計画では会場費やデポジットなどの既に確定した費用を最初に確認し、食品予算をイベント全体の予算と誤認する罠を防ぎます。また、イベントが複数サイトで行われる場合(例:音楽ステージと宿泊施設が離れている)、消耗品の配置、燃料や工具の所在、搬入作業、夜間の移動経路(安全面)、さらに各サイトに責任者が必要となるなど、想定以上に多くの影響が生じます。参加者の所有機材を事前に把握することでレンタル費用を削減でき、グループ固有のプロファイル(過去のメニュー、使用店舗、参加者傾向)を再利用することで、毎回の計画入力を最小限に抑えることが可能です。本スキルは、これらの知識をイベント間で保持するための仕組みと、新しいイベントの制約に対して過去のメニューを無批判に流用しないためのチェックポイントも提供します。

対応✓Claude Code~Codex CLI~Cursor
npx skills add Denkos-DS/event-prep

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

Event Prep(イベント準備)

グループイベントは予測可能な方法で失敗します。数量が間違った人数で掛け算されたり、4つのトレイが1つのオーブンに入らないことを当日になって発見したり、誰も起きていない朝のために朝食が買われたり、ビーガンのゲストが何も食べられなかったり、予算が紙の上ではバランスしているが、ある項目は誰も確認していない見積もりだったりします。

このスキルは、これらの計算と失敗モードをエンコードし、毎回再発見する必要をなくします。

作業の順序が重要

メニューから始めてはいけません。メニューは、確立するのが安価で、間違えると高くつく7つのことの後工程です:

  1. 人数(食事制限の内訳を含む)。「30人」では不十分です。「通常26人、ビーガン7人」は食事ごとに変わります。
  2. 到着時刻と出発時刻。これらは、どの食事が実際に存在するかを決定します。午後7時の到着は到着日の朝食がなく、最初の夕食が遅くなることを意味します。出発日の朝は、コーヒーと残り物であり、調理された朝食ではありません。
  3. 門限や厳格な時間制約。人々が予想する以上に影響が連鎖します—以下の「門限の連鎖」を参照。
  4. 会場の収容能力—まず建物があるかどうかから始める。建物は、静かに水、冷蔵、調理、電力、シェルター、トイレ、廃棄物処理を提供します。それを取り除くと、これらのすべてが、重量、コスト、所有者が付いた項目になります。その後、オーブン、冷蔵庫、冷凍庫、電気回路、近くに店があるかどうかを確認します。計画する前に、後ではなく、尋ねてください。
  5. サイトの数と、それらの距離。1つと決めつけないでください。以下の「これが発生する場所がいくつあるか尋ねる」を参照。
  6. 既に確定しているものと、集金中のもの。以下の「何かをコスト計算する前に予算全体を把握する」を参照。
  7. 既に所有しているもの。以下の「ガレージにあるものを尋ねる」を参照。

次に予算、メニュー、数量、調達元、タイムライン、そして書類です。

何かをコスト計算する前に予算全体を把握する

単一のアイテムの価格設定をする前に、何が既に確定・支払われているかを尋ねてください。 会場費、レンタル料、デポジット、装飾費 — これらは誰も食べ物のことを考える前に発生し、計画担当者は通常、これらは決着済みなので数えなくなっています。

これを省略すると、食料予算がイベント予算と誤認されます。元のイベントでは、飲食費は実際のコストの4分の1未満であり、会場費だけで半分以上を占めていました—そしてグループが実際に負担すべき一人当たりの金額はどこにも計算されていませんでした。何も隠されていませんでした。誰も尋ねませんでした。

受け入れ時に3つの数値を確立します:

  • 確定(Committed) — 既に合意または支払い済みのもの、明細付き。
  • 集金済み(Collected) — 一人当たり、そして実際に支払っている人数。これはあなたが料理する人数と常に同じとは限りません。
  • 見積もり(Estimated) — あなたがこれから計画しようとしているもの。

その後、以下のセクションに従って調整します。「2,850ドルあります」と提示された予算は、ほぼ常により大きな全体像の一部です。どの行かを尋ねてください。

これが発生する場所がいくつあるか尋ねる

イベントが一つの場所で発生すると決めつけないでください。 直接尋ねてください:いくつのサイトか、どのくらい離れているか、それらの間の車両アクセスはあるか、どこに商用電源があり、どこにないか、それらの間の経路は照明があるか。

2つ目のサイトは、見た目以上に多くのものを変えます。元のイベントでは、音楽ステージは宿泊施設から徒歩10分の場所にあり、計画のすべての物流の前提が、それが真実ではないことに静かに依存していました:

  • 消費されるものはすべて、人がいる場所になければなりません。 飲み物のために誰も往復20分歩かないので、飲み物と氷は移動します—そして屋外のクーラーは冷蔵庫ではありません。一つの場所に対して計算された数量は、二つの場所では間違っています。
  • 燃料、予備部品、工具はそれを使用するサイトに属します。 燃料が10分離れた場所にある状態で演奏中に燃料切れになると、それは25分の沈黙です。
  • 搬入は、名前が付けられたスケジュールされたタスクになります。 自発的に起こるものではありません。
  • 門限は、沈黙だけでなく、移動を引き起こします。 深夜の食べ物は、人々が他のサイトに向かう前に目的地に置いてください。
  • サイト間の経路は、一つの項目です。 数時間の飲酒の後、午後11時に照明のない地面を33人が歩くことは、週末の中で最も結果の大きいリスクであり、経路の照明は事前にはほとんどコストがかからず、夜には入手不可能です。
  • 二つのサイトには二人の責任者が必要です。 そしてそれらは同じ人物であってはなりません。

キャンプ旅行やフェスティバルキャンプは、定義上、マルチサイトです—ステージ、テント、水、調理場は四つの異なる場所にあります。単一サイトをデフォルトではなく、特殊なケースとして扱ってください。

ガレージにあるものを尋ねる

レンタルや購入の規模を決める前に、何を既に所有しているか尋ねてください。 ポータブル電源、ソーラーパネル、クーラー、スピーカー、テント、折りたたみテーブル、車両。物流の問題に対する答えは、多くの場合、すでに誰かのガレージにあります。そして、レンタルするものだけを尋ねるプロセスは、それを見つけることが決してありません。

適切に尋ねる価値がある理由は二つあります:

  • 誰も自分の装備を記憶から正確に暗唱できません。 不完全な状態で、型番が欠落して、複数のメッセージにわたって届くことを想定してください。人々がそのものに対して使用する名前ではなく、ラベルに印刷された番号を尋ねてください。
  • それはイベント間で永続化されるべきです。 これは最も再利用可能な受け入れ情報の一つであり、毎回再確立することが人々がプロセスを使わなくなる主な理由です。

繰り返しイベント

このグループがこれを以前に行ったことがあるか尋ねてください。 ほとんどのグループは初めてのイベントを計画しているわけではありません—彼らには戻ってくるメニュー、いつも使う店、ほとんど動かない参加者数があります。それが真実である場合、受け入れのほとんどは既に答えられており、再び尋ねることが人々がプロセスを使わなくなる主な理由です。

イベント間で保持する価値があるものが三つあります。これらは個人的かつローカルなものであるため、プロジェクト知識またはプライベートな作業フォルダに属し、スキル自体には含めません:

  • 店舗名簿(Store roster)。 各店舗が本当に得意とするもの、営業時間、電話番号、大口注文のリードタイム、数量割引の基準、そしてどのアイテムがそこで代替不可能か。ルートも記録してください—同じ道路にある二つの店舗は一回の移動であり、それは個々の価格よりも重要です。
  • 定番メニュー(Standing menu)。 グループが実際に戻ってくる料理。バッチ合計ではなく一人当たりの割合として保持し、それぞれに調達元の店舗と必要な機器を関連付けます。割合は任意の人数にスケールします;昨年のイベントからの合計は今回のイベントでは間違っており、正しく見えます。
  • グループプロフィール(Group profile)。 繰り返し発生する人数と食事制限の内訳、飲酒率、誰が料理するか、誰が音響とレンタルを担当するか、一人当たりいくら集金するか。

その効果は複利的です:既知のグループと既知の会場に対する受け入れは、12の質問ではなく3つの質問で済むはずであり、数量は再導出される必要がなくなります—それがずれる原因です。

しかし、定番メニューはイベントの形状変化に耐えられません。これが罠です。 料理はグループが持つ最も再利用可能なものなので、精査されずに次のイベントに持ち越されます。シャレーメニューをキャンプ場に移植すると、すべてのオーブン料理が静かに調理方法を失います;フェスティバルに移植すると、ガラス禁止だけで飲み物のルートが変わります。新しい制約に対して定番メニューを、料理ごとに、コスト計算する前に再確認してください — どの料理が持ち運び可能で、どの料理が建物なしでは同等品を持たないかについては、references/camping-and-festivals.mdを参照してください。

同じように見えて異なる数量

この分野は、一つの特徴的な方法で間違えます:二つの数量が名前または単位を共有し、異なる意味を持ち、計画はミスが行われた場所とは無関係な場所で失敗します。 既知の事例を三つ:

記載されているもの実際のもの
骨あり肉 vs 骨なし肉5 kgの肉3.5 kgの肉
ワット vs ワット時「どれだけの電力」何を接続できるか vs どのくらいの時間
mAh vs ワット時何かが136,000約327 Whの使用可能量

二つの意味があり得る単位で数値が届くたびに、それを拡大する前にどちらかを確定してください。 どちらを仮定したかを明確に述べてください。上記の三つ以外にもあるでしょう—馴染みのない単位は、値としてではなく質問として扱ってください。

門限の連鎖

音楽を午後11時に止めなければならない場合、パーティーは早く始まります。パーティーが早く始まる場合、メインの食事は午後半ばに移動します。メインの食事が午後3時の場合、就寝時間までに長い間隔ができ、その間に飲酒があり、それを埋める計画がありません。

その間隔こそが、「食べ物が多すぎる」が「午後10時に食べ物がなくなった」に変わる場所です。残り物は無駄ではなくなり、計画の一部になります。書類に明示的にそう述べてください。さもなければ、人々は夕食で終わりだと想定するでしょう。

騒音に関する門限、会場の静穏時間、固定された時間について常に尋ねてください。他のすべてはそれらに合わせて曲がります。

未解決の質問には回答だけでなく期限が必要

すべての計画には未解決の質問が蓄積されます。回答が実行可能でなくなる日時で並べ替えてください。トピックで並べ替えないでください — そうしないと、緊急の質問が単に未解決のものの中に隠れてしまいます。

メカニズムは、質問がそのトピックの下に分類されることです。土曜日に関する質問は土曜日の問題のように感じられます。しかし、それに答える唯一の方法が、営業時間内に行われる2日前通知の注文である場合、それは水曜日の問題であり、回答されずに期限切れになります。

それがまさに元のイベントで起こったことです。「土曜日のブランチは着席形式の食事ですか?」 は 「未解決、ブロックはしていない」 という見出しのリストにありました。唯一の修正はより多くのパンでした;パンは計画自体が「飛び込み注文ではない」と呼ぶ5ダースの注文でした;電話をかけられる最終日に店は午後6時に閉まりました。リスト上で最も時間的に重要なアイテムが、最も重要でないものとして分類されました。

すべての未解決の質問に、それがゲートするもののリードタイムから導出された決定期限を与えてください:

  • サプライヤーの通知期間と最小注文リードタイム
  • 店舗とサプライヤーの営業時間(残っている特定の日)
  • 集荷と配送の時間枠
  • レンタルの受け取りと返却の期限
  • 当日購入できないため事前に購入しなければならないものすべて

次に、リストを期限順に並べ替え、各行に日付を付けて提示してください。 期限のない質問は、本当にブロックしていません。期限が今日である質問は、それが何に関するものであれ一番上に属します。

リファレンスファイル

一度にすべて読むのではなく、必要に応じて読んでください:

  • references/quantities.md — 飲食の一人当たり計算、骨あり肉の補正、掛け算のルール、食欲減衰曲線、すべての数量が持つ物理的なフットプリント(質量、何が冷蔵を必要とするか、どのサイトか)。参加者数を購入量に変換するときに読んでください。
  • references/logistics.md — 会場の制約、マルチサイト計画、あらゆる形態の電力(回路、発電機、バッテリーステーション、ソーラー、車両給電)、音響システムのサイジング、調理タイムラインの構築、輸送とコールドチェーン。会場、レンタル、電気、または調理日のスケジュールに関わるものすべてに読んでください。
  • references/camping-and-festivals.md — 建物のないイベント。項目としての水、オーブンなしの調理、冷蔵庫なしの冷却、日数をまたがる食品安全曲線、燃料、日陰、衛生、廃棄物、そして計画全体を変更するフェスティバルの入場ルール。キッチンがないときはいつでも、logistics.mdと一緒に、その代わりではなく読んでください。
  • references/documents.md — 核となる書類セット、イベントに実際に必要な書類の数、それぞれの対象者、各書類に何を入れて何を入れないか。成果物を作成する前に読んでください。

既存計画の監査

人々は、しばしば既に草稿されたメニューやリストを持ってきます。時には別の場所で生成されたものです。それを基に構築する前に監査してください。これらのエラーは頻繁に発生します:

  • 日ごとの数量が決して乗算されていない。 朝食セクションに「数量は一日あたり」とあり、統合リストに同じ数字が載っています。すべての合計が実際に合計であることを確認してください。
  • 存在しない食事。 人々が夕方に到着する到着日の朝食;出発日の完全な調理済み朝食。
  • 骨あり重量が可食重量として扱われている。 quantities.mdを参照してください。
  • 調味料と香味野菜が完全に欠落している。 塩、コショウ、食用油、ガーリックパウダー、オニオンパウダーはレシピにありますが、リストにはないことが非常に多いです。リストを一行ずつ項目化することがこれらを浮き彫りにします—それを実行してください。
  • 料理の付け合わせが記憶ではなく作り出されている。 計画がレモンウェッジ付きのシシュタウクと述べている場合、または料理にその料理と合わない付け合わせを与えている場合、尋ねてください。タウクにはトゥムが合います。
  • 食事制限サブグループが夕食ではカバーされているが朝食ではカバーされていない。 見逃しやすく、影響を受ける人にとっては非常に目立ちます。
  • 実際には大きな予算の一部である予算。 計画が飲食費のみを計上し、会場費に言及しない場合、それはイベント予算ではありません。一人当たりの金額を信じる前に、他に何が確定しているか尋ねてください。
  • レンタル品が価格設定されているが、仕様がない。 発電機、音響システム、またはバンが、容量が添付されずにコストとして表示される場合、誰もそれが負荷を処理できるか確認していないことを意味します。
  • すべてが一つの場所にあると仮定されている。 パーティー、キッチン、冷蔵庫、ベッドが実際に同じ場所かどうか確認してください。計画はそうでない場合にほとんど述べません。
  • 持続負荷がカウントされていない。 無人で動作するもの(クーラー、冷蔵庫、照明)は、誰かが見ている時間ではなく、実際に動作する時間を掛け合わせます。
  • 互いに矛盾する書類。 計画に複数の書類がある場合、それぞれを独立して合計し、比較してください。それらは両方向にずれ、ずれは読んでも見えません。
  • 日付または時間について矛盾する書類。 お金は調整されます;日、日付、時計の時間はほとんど調整されません。サプライヤーに1日遅れて電話することは、合計が合わないことと同じくらい破綻しています。
  • 期限が添付されていない未解決の質問。 リードタイムのある注文、予約、または購入をゲートする未解決のものはすべて、「イベントの前に」ではなく、そのリードタイムより前に期限が来ます。リストを期限で並べ替えて、何が動くか見てください。
  • 物理的フットプリントのない数量。 価格はあるが、それがどのくらいのスペースを取り、重量があり、冷蔵を必要とするか、どのサイトに行くかを述べていない行。

関連スキル