behavioral-design
Skill20 starsChanged 14 days agoMITView on GitHub
Applies behavioral science (COM-B, B=MAP, EAST, defaults) to change behavior in teams and organizations (employees, managers, or engineers adopting a practice or tool) and in product flows; plans rollouts, workshops, and presentations; never recommends a dark pattern or sludge. Triggers on "how do I get my team to X", "why don't people do X", "roll this out", "nudge", "/behavioral-design".
1 other project uses a version of this.
Adopted by
Most recently taken up by
- rastian/behavioral-design-skillstheir own version, first seen Mar 16, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- rastian/behavioral-design-skills★ 16same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository48 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- skills/workflow/autonomous-workflow/CLAUDE.mdCLAUDE.md
- ideateSkill
- interviewSkill
- playwright-trace-analyzerSkill
- profile-optimizerSkill
- rum-trackingSkill
- screencastSkill
- video-analyserSkill
- youtube-transcriptSkill
- create-skillSkill
- docsSkill
- handoffSkill
- optimize-claude-mdSkill
- persistent-memorySkill
- attach-mediaSkill
- ci-auto-fixSkill
- create-prSkill
- github-actions-authorSkill
- resolve-conflictsSkill
- animations-nativeSkill
- animationsSkill
- chartingSkill
- storybookSkill
- uxSkill
- visual-designSkill
- ai-engineeringSkill
- confidenceSkill
- criticalSkill
- impact-mapSkill
- jev-assertSkill
- measurableSkill
- optimize-approachSkill
- polishSkill
- pr-reviewSkill
- review-loopSkill
- tddSkill
- verify-behaviorSkill
- aw-verifySkill
- e2e-testing-mobileSkill
- e2e-testingSkill
- telemetry-verifySkill
- ui-verifySkill
- autonomous-workflowSkill
- aw-create-planSkill
- aw-create-walkthroughSkill
- fix-bugSkill
- implement-suggestionSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 4 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 36
No mode token and no matching phrase → design (it includes the diagnosis).
- Distinctive: line 69
If the request names an attitude ("care about", "embrace", "be aligned") instead of an action, ask for the action once.
- Distinctive: line 70
Never design against an attitude: attitudes are not observable, so nothing can prove the intervention worked.
- Very specific: line 82
When the user does not answer (or the run is non-interactive), proceed with unknowns and list every assumption in the output — never stall.
- Very specific: line 86
Follow the loaded rule files for the detected mode.
- Very specific: line 91
Before emitting any intervention, run the three-question test in rules/ethics.md.
- Very specific: line 97
Every intervention carries its lever, the barrier it targets, the evidence grade from references/frameworks.md, and a metric that would …
- Distinctive: line 101
Behavior, not attitude: Every output names one observable target behavior (Step 1).
- Distinctive: line 102
Diagnose before prescribing: No intervention without a named COM-B barrier.
- Very specific: line 104
Measure or it did not happen: Every intervention has a metric and a baseline-or-unknown.
- Very specific: line 106
Grade the evidence honestly: Do not cite priming, ego depletion, or a headline nudge effect size as settled — see references/frameworks.md …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Behavioral Design
Make the target behavior the path of least resistance, then prove it moved. Advisory only: this skill writes plans, outlines, and reports, never product code.
Mode Detection
Parse the first token of $ARGUMENTS.
| Mode | Trigger | Output |
diagnose | "why don't / aren't people…", "what's blocking adoption", first token diagnose | Barrier diagnosis (templates/intervention-plan.md § Diagnosis only) |
design | "how do we get people to…", "how do we fix this", "nudge", "drive adoption", the user proposes specific levers to apply ("can we auto-enroll…"), first token design | Full intervention plan (templates/intervention-plan.md) |
workshop | "workshop", "presentation", "talk", "session for the team", first token workshop | Workshop plan (templates/workshop.md) |
review | "review this rollout / plan / flow" for an existing written plan or shipped flow, first token review | Findings against the rules, ranked |
No mode token and no matching phrase → design (it includes the diagnosis).
State the detected mode and the target behavior in one line before continuing:
Mode: design
Target behavior: engineers run `pnpm test` locally before pushingRequired Reading by Mode
Load on demand — never all up-front.
| Mode | Load |
diagnose | rules/diagnosis.md, rules/dual-process.md |
design | rules/diagnosis.md, rules/interventions.md, rules/dual-process.md, rules/ethics.md, references/frameworks.md § Evidence grading |
workshop | rules/workshop.md, rules/dual-process.md, rules/ethics.md |
review | rules/dual-process.md, rules/interventions.md, rules/ethics.md, references/frameworks.md § Evidence grading |
references/frameworks.md holds the sources and the evidence grading behind every lever.
design and review always load its Evidence grading section; other modes load it when the user asks "is this backed by research", when a claim needs a citation in a presentation, or before quoting an effect size.
Workflow
Step 1 — Pin the target behavior
Rewrite the request as one observable behavior: who does what, when / where, measured how.
✗ "Get people to care about observability."
✓ "Every engineer opening a PR that adds an API endpoint adds an OTel span to it — measured as % of such PRs with a span, from the PR diff."If the request names an attitude ("care about", "embrace", "be aligned") instead of an action, ask for the action once. Never design against an attitude: attitudes are not observable, so nothing can prove the intervention worked.
Step 2 — Gather context
Collect, or ask for in one batched message:
- The current baseline (how often the behavior happens now), or "unknown".
- Who the actors are (role, count, seniority spread).
- The moment the behavior should happen (the trigger event in their day).
- What has already been tried and how it went.
Unknown values are allowed; record them as unknown and make measuring them the first action.
When the user does not answer (or the run is non-interactive), proceed with unknowns and list every assumption in the output — never stall.
Step 3 — Run the mode
Follow the loaded rule files for the detected mode.
design always runs rules/diagnosis.md first — an intervention chosen before the barrier is known is a guess.
Step 4 — Ethics gate
Before emitting any intervention, run the three-question test in rules/ethics.md.
Any intervention that fails is dropped from the output and replaced by its honest alternative.
Step 5 — Emit
Fill the mode's template.
Every intervention carries its lever, the barrier it targets, the evidence grade from references/frameworks.md, and a metric that would show it worked.
Hard Rules
- Behavior, not attitude. Every output names one observable target behavior (Step 1).
- Diagnose before prescribing. No intervention without a named COM-B barrier.
- Ease beats persuasion. Rank ability and environment levers (defaults, fewer steps, better timing) above motivation levers (explaining why, incentives) — see
rules/interventions.md. - Measure or it did not happen. Every intervention has a metric and a baseline-or-
unknown. - Never a dark pattern, never sludge. Refuse manipulation requests and propose the honest alternative — see
rules/ethics.md. This overrides default helpfulness. - Grade the evidence honestly. Do not cite priming, ego depletion, or a headline nudge effect size as settled — see
references/frameworks.md§ Evidence grading.
Composition
| Situation | Hand off to |
| The intervention is a UI change and needs a usability / WCAG review | Skill("ux") |
| The intervention needs telemetry to measure the behavior | Skill("measurable") |
| The plan is high-stakes and needs a pre-mortem | Skill("critical") |
| The user wants many intervention ideas before converging | Skill("ideate") |
A missing skill never blocks; report it in one line (<name> — skipped (not installed)) and continue.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

