Tool Adoption Friction Detector
Diagnose why the tracker isn't used and design a workable adoption contract
Tool fragmentation often results from perceived complexity, slowness, notification overload, and missing integrations. This recipe diagnoses adoption blockers and outputs a lightweight working agreement on what must be tracked where, plus notification and workflow simplification suggestions.
PROMPT
Create a skill called "Tool Adoption Friction Detector". Input: my tool stack + examples of where tracking is failing. Output: a diagnosis and a one-page adoption contract. Requirements: - Identify friction drivers (complexity, speed, notifications, integrations, role mismatch). - Define minimal required tracking behaviors (decisions, commitments, scope changes, owners/dates). - Recommend workflow simplifications and notification tuning rules. - Produce a short "tracking working agreement" I can share with leadership and teams. Guardrails: - Do not assume people will change tools; optimize for bridging and simplifying first. - Keep recommendations actionable and minimally disruptive.
How It Works
Describe your current tool stack and where work actually happens (vs where it's supposed
to happen). The recipe identifies the top friction drivers per role, separates necessary
complexity from accidental complexity, defines minimum required tracking behaviors, and
produces a one-page working agreement you can share with leadership and teams.
What You Get
- Adoption diagnosis: top 5 friction drivers (complexity, speed, notifications, integrations, role mismatch)
- Tracking contract: what MUST be captured — decisions, commitments, scope changes, owners/dates
- Simplification plan: fields to remove, workflows to shorten, notification rules to tune
- Integration priorities: which bridges remove the most manual work
- One-page working agreement: ready to circulate for sign-off
Setup Steps
- List your current tools and where work actually happens (not just where it should)
- Describe user roles: exec, stakeholder, contributor — and their pain points
- Walk through a few example workflows (intake → delivery → reporting)
- Review the diagnosis and working agreement
Tips
- Optimizes for bridging and simplifying first — not replacing tools
- Stakeholder modes: never logs in, occasional, or power user
- Notification policies: minimal, balanced, or verbose
- Strictness levels: lite (suggestions), standard, or strict (requirements)
- Recommendations are actionable and minimally disruptive — no "rip and replace" proposals