agentleFS
mthinesmthines/agent-skills/skills/design/behavioral-design/SKILL.md

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

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
  1. Very specific:

    No mode token and no matching phrase → design (it includes the diagnosis).

    line 36
  2. Distinctive:

    If the request names an attitude ("care about", "embrace", "be aligned") instead of an action, ask for the action once.

    line 69
  3. Distinctive:

    Never design against an attitude: attitudes are not observable, so nothing can prove the intervention worked.

    line 70
  4. Very specific:

    When the user does not answer (or the run is non-interactive), proceed with unknowns and list every assumption in the output — never stall.

    line 82
  5. Very specific:

    Follow the loaded rule files for the detected mode.

    line 86
  6. Very specific:

    Before emitting any intervention, run the three-question test in rules/ethics.md.

    line 91
  7. Very specific:

    Every intervention carries its lever, the barrier it targets, the evidence grade from references/frameworks.md, and a metric that would …

    line 97
  8. Distinctive:

    Behavior, not attitude: Every output names one observable target behavior (Step 1).

    line 101
  9. Distinctive:

    Diagnose before prescribing: No intervention without a named COM-B barrier.

    line 102
  10. Very specific:

    Measure or it did not happen: Every intervention has a metric and a baseline-or-unknown.

    line 104
  11. Very specific:

    Grade the evidence honestly: Do not cite priming, ego depletion, or a headline nudge effect size as settled — see references/frameworks.md …

    line 106

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.

ModeTriggerOutput
diagnose"why don't / aren't people…", "what's blocking adoption", first token diagnoseBarrier 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 designFull intervention plan (templates/intervention-plan.md)
workshop"workshop", "presentation", "talk", "session for the team", first token workshopWorkshop plan (templates/workshop.md)
review"review this rollout / plan / flow" for an existing written plan or shipped flow, first token reviewFindings 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 pushing

Required Reading by Mode

Load on demand — never all up-front.

ModeLoad
diagnoserules/diagnosis.md, rules/dual-process.md
designrules/diagnosis.md, rules/interventions.md, rules/dual-process.md, rules/ethics.md, references/frameworks.md § Evidence grading
workshoprules/workshop.md, rules/dual-process.md, rules/ethics.md
reviewrules/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:

  1. The current baseline (how often the behavior happens now), or "unknown".
  2. Who the actors are (role, count, seniority spread).
  3. The moment the behavior should happen (the trigger event in their day).
  4. 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

  1. Behavior, not attitude. Every output names one observable target behavior (Step 1).
  2. Diagnose before prescribing. No intervention without a named COM-B barrier.
  3. Ease beats persuasion. Rank ability and environment levers (defaults, fewer steps, better timing) above motivation levers (explaining why, incentives) — see rules/interventions.md.
  4. Measure or it did not happen. Every intervention has a metric and a baseline-or-unknown.
  5. Never a dark pattern, never sludge. Refuse manipulation requests and propose the honest alternative — see rules/ethics.md. This overrides default helpfulness.
  6. 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

SituationHand off to
The intervention is a UI change and needs a usability / WCAG reviewSkill("ux")
The intervention needs telemetry to measure the behaviorSkill("measurable")
The plan is high-stakes and needs a pre-mortemSkill("critical")
The user wants many intervention ideas before convergingSkill("ideate")

A missing skill never blocks; report it in one line (<name> — skipped (not installed)) and continue.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.