スキル payoff-action-modeling
📦

payoff-action-modeling

安全

ユーザーの意図質問からUIアクションモデルを設計する

プロダクトチームは、ユーザーがタスクを完了した後にどのUIアクションを表示すべきかの判断に苦労しています。このスキルは、ユーザーの意図からアクションをモデル化するための構造化されたフレームワークを提供し、適切なスコープと優先順位に配置します。

対応: Claude Codex Code(CC)
📊 71 十分
1

スキルZIPをダウンロード

2

Claudeでアップロード

設定 → 機能 → スキル → スキルをアップロードへ移動

3

オンにして利用開始

テストする

「payoff-action-modeling」を使用しています。 After a user imports customer data from a CSV file, what actions should the UI show?

期待される結果:

  • Outcome state type: handoff with review
  • Primary CTA: Review import results
  • Contextual actions: Map field (per column), Fix row (per error), Download error file
  • Continuation branches: Import more, Start new import
  • Recovery actions: Undo import, View import history
  • Placement notes: Error rows show Fix inline, success summary at top with Review CTA

「payoff-action-modeling」を使用しています。 Our file upload completion screen shows Download, Share, Delete, Rename, Move, Copy link, and Add description all at the same level. What is wrong with this?

期待される結果:

  • Issue 1: No primary CTA - 7 actions at equal visual weight creates decision fatigue
  • Issue 2: Download should be primary CTA (highest-value next action)
  • Issue 3: Delete is destructive and should be contextual with recovery path, not at top level
  • Issue 4: Move and Copy link are deferred actions that can go in a secondary menu
  • Issue 5: Add description is a refinement action, not an outcome action
  • Proposed: Primary CTA: Download | Secondary: Share, Copy link | Menu: Rename, Move | Contextual with confirm: Delete

セキュリティ監査

安全
v3 • 5/26/2026

All 142 static analysis findings are false positives. The skill is a pure documentation guide for UX/UI product design. Backtick characters flagged as 'shell execution' are standard Markdown inline code formatting for UI action labels. Findings flagged as 'weak cryptographic algorithm' are markdown table content, YAML frontmatter, and UX guidance text with no cryptographic content. The single URL reference to casely.digital is a passive documentation mention, not executable network code. No executable code, data exfiltration, command injection, or environmental access was found.

2
スキャンされたファイル
304
解析された行数
1
検出結果
3
総監査数
低リスクの問題 (1)
External URL reference in documentation
SKILL.md line 298 contains a URL to casely.digital in a documentation note. This is a passive reference suggesting a hosted tool, not an executable network request. The URL is clearly documented as an optional mention. No data transmission or credential exposure risk.
監査者: claude 監査履歴を表示 →

品質スコア

38
アーキテクチャ
100
保守性
87
コンテンツ
30
コミュニティ
100
セキュリティ
91
仕様準拠

作れるもの

オンボーディング後のアクション画面を設計する

このフレームワークを使用して、ユーザーがオンボーディング、セットアップ、初回設定を完了した後に表示するアクションを決定します。新しいユーザーを圧倒することなく、明確な次のステップを提供します。

ダッシュボードのアクション階層を計画する

ダッシュボードやワークスペースのアクションを、アウトカム、選択、アイテム、ナビゲーション、リカバリの各スコープに分類し、適切な緊急度レベルを割り当てて整理します。

既存インターフェースのアクション明確性をレビューする

既存のUIをアウトカムモデリングの原則に照らして監査し、重複したアクション、曖昧なラベル、競合するプライマリCTAを特定します。具体的な改善計画を作成します。

これらのプロンプトを試す

基本的なアウトカムアクションモデル
I just built a file upload feature for my app. After a user uploads a file, I need to model what actions to show on the completion screen. Use the outcome action modeling framework to produce a simple action model table with scope, pressure, and placement for at least 8 actions.
完全なダッシュボードアクションモデル
I am designing a project management dashboard that appears after a user creates a new project. The dashboard shows tasks, team members, and recent activity. Use the full outcome action modeling framework to classify the outcome state, generate at least 15 user intent questions, and produce an action table with all scopes, pressures, and placements.
エッジケースを含むマルチスコープワークフロー
I am designing a data import flow where users upload a CSV, map fields, review results, and handle errors. The post-import screen needs to support retry failed items, download error logs, approve mapped rows, and export results. Use the framework with special attention to recovery actions, ambiguous scope boundaries, and intent pressure conflicts. Add edge case handling for partial failures.
既存アクションモデルのレビューと最適化
I have an existing action model for a content management system publish screen. The current model has 12 actions all shown at the same level. Use the framework to review this model for density issues, scope ambiguity, label clarity, and momentum problems. Identify at least 5 specific issues and propose a revised action table.

ベストプラクティス

  • アクションを配置する前に、まずアウトカム状態のタイプを定義すること。これがアクション階層全体を決定します。
  • アウトカム画面ごとに明確なプライマリCTAを1つに保つこと。複数のプライマリレベルのアクションは意思決定疲れを引き起こします。
  • 実装の詳細ではなく、ユーザーのアウトカムを説明する具体的なアクションラベルを使用すること。

回避

  • 初回成功画面に可能なすべてのアクションを詰め込みすぎないこと。高度な機能はセカンダリメニューに移すこと。
  • すべてのアクションを視覚的階層で同等に扱わないこと。インテントプレッシャーを使用して、即時アクション、コンテキストアクション、延期アクションを区別すること。
  • 元に戻すや再試行などの重要なリカバリアクションを汎用メニューの背後に隠さないこと。それらがリカバリ対象の状態の近くに配置すること。

よくある質問

このフレームワークはどのようなタイプのプロダクト画面で機能しますか?
このフレームワークは、ユーザーが意味のあるアウトカムを達成したあらゆる画面で機能します。これには、完了状態、生成結果、ワークスペース、レビュー画面、ハンドオフフロー、リカバリ状態、継続ブランチが含まれます。
1つの画面にいくつのアクションを表示すべきですか?
固定された数はありませんが、フレームワークは1つの明確なプライマリCTAとグループ化されたコンテキストアクションを推奨します。一度に表示するアクションは5〜7個以下に抑えてください。緊急度の低いアクションはセカンダリメニューに移してください。
このフレームワークはユーザーリサーチを代替しますか?
いいえ。このフレームワークは、一般的なUIパターンに基づいた構造化された出発点を提供します。ユーザーテストやドメイン固有のリサーチによって検証される必要があります。
アウトカムスコープとアイテムスコープの違いは何ですか?
アウトカムスコープのアクションは「すべてダウンロード」や「すべて公開」など、結果全体に影響します。アイテムスコープのアクションは、特定の行に対する「編集」や「削除」など、1つのアイテムに影響します。これらのスコープは、明確に異なるラベルと配置を持たなければなりません。
モデル内で破壊的なアクションはどのように扱えばよいですか?
破壊的なアクションはコンテキストに応じて配置し、リカバリパスと組み合わせる必要があります。プライマリCTAではなく、影響を与えるオブジェクトの近くに配置してください。常に確認、元に戻す、アーカイブ機能を含めてください。
モバイルUIデザインにもこのフレームワークを使用できますか?
はい、ただし小さな画面向けに配置ガイドラインを調整してください。モバイルレイアウトでは、より多くのアクションをメニューやボトムシートの背後に配置する必要がある場合があります。スコープとプレッシャーの分類は引き続き適用されます。

開発者の詳細

ファイル構成

📁 agents/

📄 openai.yaml

📄 SKILL.md