mcpField
J
joke-engineering

joke-engineering

github.com/jwyniaクリエイティブ・メディア179681 回インストール35 週間前に更新
リポジトリ

joke-engineering について

joke-engineeringは、ジョークを体系的に分析・改稿したい創作者向けの診断スキルです。意外性、明瞭さ、つながりの密度、簡潔さなどを調べ、改稿前後の例を示します。

主な機能

  1. 01よくある6種類の問題を診断
  2. 02ジョークの9つの特性を分析
  3. 03概念間のつながりを整理
  4. 04問題に応じた修正案を提示
  5. 05改稿前後の例を作成
  6. 06診断内容をファイルに保存

活用シーン

  1. 01ジョークが予測可能または難解な理由の特定
  2. 02説明過多の導入部分の短縮
  3. 03明瞭さを保ちながら層を加える調整
  4. 04創作者の語り口に合う素材への改稿

インストール

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

$npx skills add https://github.com/jwynia/agent-skills --skill joke-engineering

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

詳細

ジョークエンジニアリング:診断スキル

ユーモアがうまく機能しない理由を診断し、より効果的なジョークを作るお手伝いをします。ジョークの構造をつながりのシステムとして分析し、具体的な改善策を提案するのが役割です。

基本原則

ユーモアは、概念、枠組み、参照点のあいだにつながりを生み出し、それを解決することで生まれます。

ジョークは、特性を測定できるシステムです。ユーモアがうまく機能しないときは、システムの特性が1つ以上、適切に調整されていません。このスキルでは、どの特性を調整すべきかを特定します。

9つのシステム特性

効果的なジョークは、相互につながった次の特性のバランスが取れています。

特性説明うまく機能しない場合
つながりの距離つながっている要素間の意味上の隔たりわかりやすすぎる(退屈)か、わかりにくすぎる(混乱する)
つながりの密度補強し合うつながりの数つながりが1つだけのジョークは薄く感じられる
解決の満足感「わかった」ときの認知的な報酬無理がある、または論理に欠けるオチ
具体性の最適化細部の精度一般的な描写ではインパクトに欠ける
皮肉の重層性入れ子になった矛盾深みのない平板な皮肉
オーディエンスの共同創作オーディエンスがつながりを完成させる余地説明しすぎたジョークは笑いを台無しにする
圧縮の最適化言葉数に対するつながりの比率長すぎる前振りは勢いを損なう
つながりの耐性さまざまな知識領域にまたがって機能することオーディエンスが特定の知識を持たないと機能しない
真正性の共鳴作り手の語り口との一致無理がある、またはありきたりに感じられる

診断状態

ユーモアを分析するときは、当てはまる状態を特定します。

状態 H1:わかりやすすぎる

症状: ジョークの展開が予測できる。オーディエンスがオチを先読みする。つながりの距離が短すぎる。 重要な問い: 驚きを増すために、どのような予想外の枠組みの転換ができるでしょうか? 介入策: 一貫性を保ちながら、つながりの距離を広げます。

状態 H2:わかりにくすぎる

症状: オーディエンスに伝わらない。参照が専門的すぎる。つながりの隔たりが大きすぎる。 重要な問い: 説明しすぎることなく、理解を助ける手がかりをどのように加えられるでしょうか? 介入策: 文脈の手がかりを加えるか、並行するつながりの経路を作ります。

状態 H3:密度が低い

症状: ジョークが薄く感じられる。つながりが1つしかない。重層性がない。 重要な問い: 複数の枠組みで、複数の役割を果たせる要素は何でしょうか? 介入策: 循環する皮肉、再帰的なつながり、または入れ子になった不条理さを加えます。

状態 H4:説明しすぎ

症状: オチが暗示ではなく明言されている。オーディエンスが参加する余地がない。 重要な問い: つながりを保つには、何を削れますか? 介入策: 戦略的に省略し、すべてを言い切る直前で終わらせます。

状態 H5:語り口に無理がある

症状: 言葉遣いが不自然に感じられる。ジョークが作り手の視点に合っていない。 重要な問い: この人なら、この状況を自然にどう表現するでしょうか? 介入策: その人らしい語り口のパターンに合わせて、言葉遣いや枠組みを調整します。

状態 H6:圧縮不足

症状: 前振りが長すぎる。オチの前に勢いが失われる。言葉数に対するつながりの比率が低い。 重要な問い: 核となるつながりに貢献していない要素は何でしょうか? 介入策: 説明的な要素を削り、明示的な表現を暗示的な表現に置き換えます。

診断プロセス

うまく機能しないジョークが提示されたときは、次の手順で進めます。

  1. 症状を聞き取る - 具体的に何が伝わっていないのでしょうか?
  2. つながりの経路をたどる - 意図されているつながりはどこにあるでしょうか?
  3. 特性を測る - どのシステム特性が適切に調整されていないでしょうか?
  4. 状態を特定する - 上記の診断状態に当てはめます。
  5. 介入策を提案する - 実施する具体的な調整を示します。
  6. 変化を実演する - 有用であれば、修正前と修正後を示します。

主な接続タイプ

  • 矛盾:共通の枠組みの中で、互いに対立する要素
  • フレームシフト:異なる枠組みに基づく再解釈
  • 二重連想:これまで無関係だった概念的な枠組みを結び付けること
  • パターン違反:認知パターンを確立したうえで、それを破ること
  • 暗黙の接続:読者が補完できるよう、意図的に明示しない接続

密度を高めるパターン

接続の密度を高めるときは、次の方法を使います。

  • 循環する皮肉:要素が互いに矛盾する、閉じたフィードバックループを作ること
  • 再帰的な接続:自らを強化する接続
  • 複数の役割の割り当て:異なる枠組みの中で、要素が異なる機能を果たすこと
  • 自己言及システム:ジョークの構造が、その内容自体を反映すること
  • 入れ子状の不条理:実用性のなさが段階的に増し、相乗的に重なる層

皮肉のグラデーション

最も効果的なジョークでは、要素の重要度に一定の変化を持たせています。

  • 多大な労力 → 重要性の低いもの
  • 高い精度 → 的外れな対象
  • 完璧な実行 → 不要な作業
  • 複雑なシステム → 単純なニーズ

圧縮のテクニック

冗長さを減らすときは、次の方法を使います。

  1. 複数の接続機能を果たす要素を残します
  2. 接続を生み出すのではなく説明する要素を取り除きます
  3. 明示的な表現を、構造から読み取れる含意に置き換えます
  4. 複数の接続を強化する具体性を保ちます
  5. 読者が補完できる余地を戦略的に設けます

評価マトリクス

指標効果が低い効果が高い
接続距離あまりに明白、またはあまりに難解意外性がありながら理解できる
接続の一貫性無理がある、または非論理的明快で、納得のいく結末
接続密度単一で直線的な接続複数の接続が互いを強化する
認知的バランス単純すぎる、または複雑すぎる適切な難易度
補完の余地説明しすぎ、または達成不可能読者が無理なく補完できる
圧縮単語数に対する接続の割合が低い単語数に対する接続の割合が高い
汎用性特定の知識がないと成立しない幅広い分野で通用する
自然さありきたり、または不自然な語り口自然な視点

変換例

元の例(状態 H3 + H6:密度が低く、冗長)

「テレビを見すぎると脳が腐ると言っていたベビーブーマー世代の親は、今やケーブルテレビのニュースで自分の脳を腐らせています。」

分析: 単純な偽善の接続で、一本の筋しかなく、圧縮度は中程度です。

改善例(高密度)

「『スクリーンタイムは30分まで。そうしないと脳がプリンになる』と言って私たちの時間を制限していたベビーブーマー世代の父は、また午前3時にサプリをパニック買いして、脳がちゃんとあると自ら証明していないのに、今ではニュースアプリにペアレンタルコントロールをかけてくれと私に頼んでくる。」

改善点:

  • 役割の逆転を加えました(親が子どもを制限していたのに、立場が逆転)
  • 循環する構造を作りました(脳への懸念 → メディア → サプリ → 脳がない証拠)
  • 具体的な詳細(「午前3時」「ペアレンタルコントロール」)で自然さを加えました
  • 読者が補完できるよう、暗黙の接続(どのニュースチャンネルか)を設けました
  • 皮肉のグラデーションを作りました(脳を守ろうとしながら、その不在を証明している)

ジョーク以外への応用

このフレームワークは、次の分野にも応用できます。

  • クリエイティブライティング(比喩、類推)
  • 広告(記憶に残る連想)
  • 人前でのスピーチ(印象的な逸話)
  • ユーザーエクスペリエンス(直感的な接続)
  • ナラティブデザイン(納得感のあるストーリー展開)

出力の保存

出力先の確認
  1. プロジェクト内の context/output-config.md を確認します
  2. ファイルが見つかったら、このスキルのエントリーを探します
  3. 見つからない場合は、ユーザーに「ユーモア関連の作業はどこに保存すればよいですか?」と尋ねます
  4. 次の保存先を提案します:writing/humor/ または explorations/writing/
主な出力
  • 診断状態 - 該当するユーモアの状態
  • 特性の分析 - 調整が不適切なシステム特性
  • 変換 - 理由を添えた変換前後のバージョン
  • 接続のマッピング - 接続の種類と密度
ファイル名

パターン:{project-name}-humor-{date}.md

検証(Oracle)

このスキルで検証できること
  • 状態の特定 - どの診断状態が当てはまりますか?(高い確度)
  • 特性の測定 - どの特性を調整する必要がありますか?(高い確度)
  • つながりの把握 - どのような種類のつながりが存在しますか?(中程度の確度)
人間の判断が必要なこと
  • ユーモアが伝わるか - 実際に観客にウケるでしょうか?
  • 声の真正性 - その人らしい話し方になっていますか?
  • 文脈への適切さ - この状況にふさわしいユーモアですか?
オラクルの制限
  • ユーモアが伝わるかどうかは評価できません
  • 観客が笑うかどうかは予測できません

フィードバックループ

セッションの永続化
  • 出力先: context/output-config.mdを参照してください
  • 保存する内容: 診断状態、特性の分析、変換内容
  • 命名パターン: {project-name}-humor-{date}.md
セッションをまたいだ学習
  • このプロジェクトで以前に行ったユーモア関連の作業を確認します
  • このクリエイターや観客に効果があったものを活用します
  • 失敗したジョークを特性の調整に生かします

設計上の制約

このスキルが想定すること
  • 意図的にユーモアを作り込むこと(気軽な会話ではありません)
  • 改善する価値のある素材であること(使い捨ての小ネタではありません)
  • クリエイターが体系的な分析を望んでいること
このスキルでは対応しないこと
  • 即興の機知 - 分析しすぎると面白さが損なわれます
  • 文化的なユーモアの文脈 - sensitivity-checkに引き継ぎます
  • 話し方の確立 - voice-analysisに引き継ぎます
品質低下の兆候
  • 気軽なユーモアを過剰に作り込む
  • 何よりも密度を優先する(ジョークを詰め込みすぎる)
  • 声を消してしまう(最適化によって真正性を損なう)

推論の要件

標準的な推論
  • 1つのジョークの診断
  • 基本的な特性の測定
  • 簡単な変換
拡張推論(ultrathink)
  • セットまたはルーティンの分析 - [理由:ジョーク同士が影響し合い、効果を積み重ねるため]
  • つながりの密度の最適化 - [理由:複数のつながりの層のバランスを取るため]
  • 声の統合 - [理由:変換を通じて真正性を保つため]

トリガーフレーズ: "analyze the whole set", "maximize density", "keep my voice"

実行戦略

順次実行(デフォルト)
  • 変換の前に診断します
  • 調整の前に特性を測定します
  • 評価の前に変換します
並列化できる処理
  • 互いに独立した複数のジョークを分析する
  • さまざまな変換方法を試す
サブエージェントの候補
タスクエージェントの種類起動するタイミング
声の分析汎用クリエイターらしさを保つ場合
観客の調査汎用特定の観客に合わせて調整する場合

コンテキスト管理

おおよそのトークン使用量
  • スキルの基本部分: 約3kトークン(特性+状態+手法)
  • 例を含む場合: 約4kトークン
  • すべての適用例を含む場合: 約4.5kトークン
コンテキストの最適化
  • 関連する診断状態に焦点を当てます
  • 特性は中核となるため、常に必要です
  • 適用例のセクションは任意です
コンテキストが不足してきた場合
  • 優先するもの:現在の状態、関連する特性
  • 後回しにするもの:状態の全リスト、すべての手法
  • 省くもの:適用例のセクション、評価マトリクス

アンチパターン

1. 気軽なユーモアを過剰に作り込む

パターン: 何気ない一言や気軽な機知にも、完全な診断フレームワークを適用する。 うまくいかない理由: ユーモアは、即興性や自然な流れによって効果を発揮することがよくあります。過剰な分析は、気軽なユーモアを成り立たせる軽やかさを損ないます。すべてを体系的に改善する必要はありません。 対策: 体系的な診断は、文章、プレゼンテーション、パフォーマンスなど、意図的に作り込む素材に限ります。気軽な会話はそのまま気軽なものにしておきます。

2. 何よりも密度を優先する

パターン: ジョークが重みに耐えられず崩れてしまうまで、つながりの層を加える。 うまくいかない理由: 密度が高いと、観客は複数のつながりを同時に追う必要があります。要素を詰め込みすぎたジョークは認知的な負担が大きく、解決による満足感よりも処理コストのほうが上回ります。 対策: つながりの数を最大化するのではなく、つながりと混乱の比率が最も高くなるよう最適化します。すばらしいジョークの中には、たった1つの強烈なつながりで成り立つものもあります。

3. 暗黙のつながりを説明してしまう

パターン: 読み手が「理解できる」ように、すべてのつながりを明示すること。 なぜうまくいかないのか: 解決の満足感は、読み手自身がつながりに気づくことで得られます。ジョークを説明すると、ユーモアを楽しむうえで大切な「なるほど」という瞬間を奪ってしまいます。 対策: 読み手を信頼してください。すべてを明確に言い表す少し手前で終えます。つながりが伝わりにくい場合は、説明するのではなく、手がかりとなる文脈を補います。

4. 声の消去

パターン: 作り手らしさを削ぎ落としながら、ジョークを「最適な」構成に書き直すこと。 なぜうまくいかないのか: ユーモアは個人的なものです。技術的には完璧でも、演じ手らしく聞こえないジョークは不自然に感じられます。読み手は、その理由を言葉にできなくても、偽りらしさに気づきます。 対策: 独特な言葉遣い、視点の癖、語りのリズムを保ちます。作り手の声を犠牲にするのではなく、その声を生かして最適化します。

5. 単一指標の最適化

パターン: ある特性(例:圧縮度)に集中し、それがほかの特性に与える影響を無視すること。 なぜうまくいかないのか: 9つの特性は相互に依存しています。圧縮度を最大化すると、つながりの強さが損なわれることがあります。距離を広げると、解決の満足感が大きく低下することがあります。 対策: 実際のボトルネックとなっている特性を特定します。関連する特性への影響を確認しながら調整します。

統合

受け入れ側(このスキルへの入力)
スキル提供する内容
voice-analysis作り手らしい本来の声のパターンに関する理解
dialogueキャラクターの声と会話のリズムに関するスキル
提供側(このスキルが可能にすること)
スキル提供する内容
speech-adaptationプレゼンテーションで使うユーモア要素の強化
dialogueコミカルな会話を構成するテクニック
prose-style散文における機知とコメディの間合い
補完関係
スキル関係性
cliche-transcendenceどちらも意外なつながりを活用しますが、cliche-transcendenceは予測可能なパターンを避けることに重点を置き、joke-engineeringは意外なパターンを作り出します
brainstormingBrainstormingが素材を生み出し、joke-engineeringが効果的なユーモアへと磨き上げます

コメント