4ds

A Claude Code plugin that turns feature ideas into reviewed specs, lets you explicitly hand off tasks to Claude on your own schedule, and has Claude actually carry them out — coding, research, writing, or analysis, whichever the task calls for — while keeping your own review and judgment central. Built around Anthropic's AI Fluency 4Ds framework:

D	What it means	Where it shows up here
Delegation	Deciding whether/when/how to hand work to AI	/4ds:delegate — a standalone, run-anytime command that assigns a task's Owner and, if it's Claude's, actually acts on it. Nothing happens without this explicit step.
Description	Communicating goals clearly	Real back-and-forth brainstorming, not a form to fill out
Discernment	Critically evaluating AI output	Three distinct checks — see below — not just a code review
Diligence	Taking responsibility for outcomes	You mark things "Done," not Claude; the checklists are yours to work through

Discernment is three things, not one

Anthropic's own framing of Discernment splits it into Product (is the output good), Process (did the AI get there soundly), and Performance (was the interaction itself effective) — three different questions, not one code review. This plugin keeps them as three separate mechanisms rather than conflating them into a single "review" step:

Discernment type	What it asks	How this plugin handles it
Product	Is the output itself good — accurate, coherent, relevant?	code-reviewer agent, via /4ds:discern — on-demand, checklist-driven, code-diff-focused
Process	Did the agent get there soundly — grounded, verified, logically consistent?	process-reviewer agent — runs automatically, every time, right after coder or writer finishes
Performance	Was Claude's behavior/communication during the interaction actually effective for you?	A direct reflective check-in table at the end of every /4ds:delegate run

What this plugin does — and does NOT do

• It does not write your implementation for you when you're just brainstorming. /4ds:brainstorm produces a specification document — illustrative snippets only, never a full implementation. This is deliberate: it keeps you hands-on with the work you want to stay hands-on with, and conserves usage.
• It does not decide who owns what, ever — not during brainstorming, not implicitly. Every task starts Unassigned and Unclassified, and stays that way until you run /4ds:delegate, whenever you're ready to make that call.
• It does act on a task the moment you delegate it to Claude — /4ds:delegate isn't just bookkeeping. It figures out what kind of task it actually is and dispatches to the right specialist: coder for implementation, researcher for fact-finding with citations, writer for prose deliverables, analyst for investigating what's already in the repo, or handles it directly if none of those fit.
• It stays engaged even when a task goes to you. Delegating to Human isn't just a database write — Claude checks for outstanding questions and will discuss the task with you, without doing any part of it itself.
• It tries to stop you from delegating a whole undecomposed feature in one shot, to either party. A large, multi-part chunk of work handed off wholesale is where things go wrong, regardless of who's doing it — /4ds:delegate flags an oversized task before assigning it and offers to split it first, though the final call is still yours.
• It doesn't treat "code review" as the whole of Discernment. Checking the artifact (Product) is only one of three checks — see above.
• It never decides something is "safe," "done," or "ready to ship." That judgment — Discernment and Diligence — stays yours throughout. Claude's job is to hand you concrete things to check, not to check them off for you.

Installation

As a team, via this repo as a self-hosted marketplace:

/plugin marketplace add <owner>/4ds
/plugin install 4ds@4ds-marketplace

(Replace <owner> with wherever this repo ends up hosted — fill in homepage/repository in .claude-plugin/plugin.json once it's pushed.)

For local development/testing:

claude --plugin-dir ./4ds

How it all fits together

                      /4ds:brainstorm [idea]
                                |
                                v
                    +-----------------------+
                    | Brainstorm together:  |
                    | problem, goals,       |
                    | approach              |
                    +-----------------------+
                                |
                                v
                    +-----------------------+
                    | Big enough to split   |
                    | into tasks? List them |
                    | -- Owner AND Type are |
                    | NOT decided here      |
                    +-----------------------+
                                |
                                v
                    +-----------------------+
                    | spec-writer agent     |
                    | writes                |
                    | specs/<spec-name>.md  |
                    | every task/feature =  |
                    | Unclassified,         |
                    | Unassigned            |
                    +-----------------------+
                                |
                                v
                    +-----------------------+
                    | /4ds:delegate         |     <-- run anytime: right
                    | <spec-name> [task]    |         after brainstorming,
                    |                       |         days later, whenever
                    | Scope too broad for   |         you decide
                    | one task? Flag it --  |
                    | offer to split first  |
                    | via /4ds:refine (your |
                    | call either way)      |
                    |                       |
                    | Assign Owner: Claude  |
                    | or Human              |
                    +-----------------------+
                                |
                +---------------+----------------+
                |                                 |
         Owner = Claude                     Owner = Human
                |                                 |
                v                                 v
   +--------------------------+       +--------------------------+
   | Classify Type, then      |       | Recorded as yours --      |
   | dispatch:                |       | Claude stays engaged:     |
   |                          |       | "outstanding questions?"  |
   | Coding   -> coder agent  |       | discusses/points at       |
   |            (worktree)    |       | context, does none of     |
   | Research -> researcher   |       | the work itself           |
   | Writing  -> writer agent |       +--------------------------+
   |            (worktree)    |                    |
   | Analysis -> analyst      |                    |
   | Other    -> handled      |                    |
   |            directly      |                    |
   +--------------------------+                    |
                |                                   |
        Coding/Writing only:                        |
   +--------------------------+                     |
   | process-reviewer agent   |                      |
   | (Process Discernment,    |                      |
   | automatic, not optional) |                      |
   +--------------------------+                      |
                |                                   |
     output + process-review                you implement it yourself,
     written, spec Status updated           whenever you're ready
                |                                   |
                +----------------+------------------+
                                 |
                                 v
                    +-----------------------+
                    | Performance Discernment|    <-- always, every path,
                    | check-in (table) --   |         end of every
                    | your read on how this |         /4ds:delegate run
                    | interaction went      |
                    +-----------------------+
                                 |
                                 v
                    +-----------------------+
                    | /4ds:discern           |   (Product Discernment,
                    | <spec-name> [target]   |    on-demand, code only --
                    |                        |    non-code output gets
                    | code-reviewer agent    |    read manually)
                    | checks the diff        |
                    | against the 10-item    |
                    | checklist -- reports   |
                    | findings, never a      |
                    | verdict                |
                    +-----------------------+
                                 |
                                 v
                    You decide what's actually
                    satisfied (Discernment and
                    Diligence stay yours)
                                 |
                                 v
                    +-----------------------+
                    | /4ds:refine           |
                    | <spec-name>           |
                    |                       |
                    | anytime: new info,    |
                    | scope change,         |
                    | mark Done             |
                    +-----------------------+
                                 |
                                 v
                  (loop back into /4ds:delegate,
                   /4ds:discern, or another
                   /4ds:refine as remaining
                   tasks get worked through)

Commands

/4ds:brainstorm [idea]

Start here for anything new. Claude has a real conversation with you about the problem, goals, and approach (Description). If the feature is large enough to have natural seams, it proposes breaking it into tasks — but it never decides who implements them or what kind of task each one is. The result is a spec written to specs/<spec-name>.md, with every task (or the whole feature, if it wasn't split) set to Owner: Unassigned and Type: Unclassified, plus a Product Discernment & Diligence checklist for later. <spec-name> is a short, recognizable kebab-case name you both agree on during the conversation (e.g. api-rate-limiting) — it's what you'll type into every other command below to refer back to this spec.

> /4ds:brainstorm add rate limiting to the public API
Claude: What's driving this — abuse, cost, or fairness between callers? ...
  [... conversation continues ...]
Claude: This has two natural pieces: a token-bucket limiter middleware, and
  a per-key config store. I won't assign owners yet — delegate them
  whenever you're ready with /4ds:delegate.
Claude: Wrote specs/api-rate-limiting.md — both tasks are Unassigned.

/4ds:delegate <spec-name> [task]

The actual Delegation act — and where the work actually gets done. Assigns or reassigns a task's Owner to Claude or Human, run any time, independent of when the spec was written: right after brainstorming, days later, or again if plans change.

Always operates on one well-scoped task, never a whole undecomposed feature if that can be helped — before it delegates anything, it looks at what's actually being handed off and flags it if the scope looks too broad for one person (or Claude) to safely take on in one piece, whether that's headed to a human or to Claude. You can proceed anyway if you want to; it's a heads-up, not a block.

If you assign the task to Human, that's not the end of the conversation — Claude stays engaged and asks if you have outstanding questions before stepping back, and will actually discuss the task with you (pointing at relevant code/context) without doing any part of it itself.

If you assign it to Claude, this skill immediately figures out what kind of task it is and dispatches to the right specialist:

Type	Specialist	Notes
Coding	coder agent	Isolated git worktree/branch, then process-reviewer runs automatically
Research	researcher agent	Cites sources in APA format
Writing	writer agent	Isolated git worktree/branch, then process-reviewer runs automatically
Analysis	analyst agent	Read-only investigation of the repo
Other	Claude, directly	No dedicated agent — best judgment

Reassigning a task that already has partial work prompts a check on whether its Status should reset too. Every run — regardless of Owner or Type — closes with a Performance Discernment check-in (see below).

> /4ds:delegate api-rate-limiting 1
Claude: Task 1 ("token-bucket limiter middleware") is Unassigned. Claude
  or Human?
> Human
Claude: Got it — that's yours. Any outstanding questions before you get
  started?
> what's the existing rate-limit config format?
Claude: [points to the relevant existing module] ...
> nope, good to go
Claude: Sounds good — it's recorded as yours in the spec.
  [... Performance Discernment check-in table ...]

/4ds:discern <spec-name> [target]

Product Discernment, on-demand. Runs the spec's Product Discernment & Diligence checklist against a code change — uncommitted diff, a branch from a Coding or Writing delegation, a task, or specific files. Works on code you wrote by hand just as well as Claude's output — this is meant to support your own review, not just police Claude. Reports findings by category with severity/confidence labels and file/line references; never a summary verdict. You decide which findings count as "addressed" before any checklist boxes get checked off, and Claude always asks first. (This checklist is code-diff-focused — for Research/Analysis/ Other output, review is manual: read the output file. This is Product Discernment only — Process Discernment already ran automatically if the task was Coding or Writing; see Agents below.)

/4ds:refine [spec-name]

Update an existing spec as understanding changes — new information, a resolved open question, a scope change. Edits the file in place (never regenerates it), and appends to its Revision History. Only you can move a task's Status to Done; Claude never infers that on its own.

Agents

Seven subagents back the commands above. Each is general-purpose — none of them are hard-locked to a single calling skill, so Claude can reach for any of them mid-conversation whenever they're genuinely useful, not just when /4ds:delegate is running:

Agent	Role	Tools
spec-writer	The only thing that writes/edits specs/*.md — single source of truth for spec formatting	Read, Grep, Glob, Write, Edit
coder	Implements a well-scoped coding task, isolated worktree	Read, Grep, Glob, Write, Edit, Bash
code-reviewer	Product Discernment. Reviews a code change against the checklist, read-only, on-demand (/4ds:discern)	Read, Grep, Glob, Bash (read-only use)
process-reviewer	Process Discernment. Examines how coder/writer did their work — grounding, verification, reasoning consistency — read-only, automatic (runs right after coder/writer, not on-demand)	Read, Grep, Glob, Bash (read-only use)
researcher	Gathers information (web + codebase), cites sources in APA format	Read, Grep, Glob, WebSearch, WebFetch
writer	Drafts prose deliverables grounded in given context, isolated worktree	Read, Grep, Glob, Write, Edit
analyst	Investigates existing repo data/logs/code, read-only	Read, Grep, Glob, Bash (read-only use)

coder and writer use isolation: worktree since they write directly to real project files — this means their runs never collide with your own uncommitted edits, other concurrent delegations, or a teammate's work on the same repo. process-reviewer only ever runs after one of those two — researcher and analyst don't create/modify files in the repo, so there's no process to check in the same sense.

Where specs and outputs live

• specs/<spec-name>.md — one file per feature, the planning/tracking document. <spec-name> is the same short, kebab-case name you use with every command. If a spec with that name already exists, /4ds:brainstorm won't overwrite it — it points you to /4ds:refine instead.
• outputs/<spec-name>-task-<#>.md (or outputs/<spec-name>.md for a single-task spec) — where Research and Analysis deliverables land, and where Writing deliverables land unless the task clearly targets a real project file instead (e.g. "update the README").
• outputs/<spec-name>-task-<#>-process-review.md — process-reviewer's report, saved automatically after every Coding or Writing delegation.
• Coding (and file-targeted Writing) deliverables land as commits on a dedicated branch in an isolated worktree, reported back to you with the branch name and path.

The Product Discernment & Diligence checklist

Every spec gets a fixed set of 10 categories — this is the Product check specifically (see "Discernment is three things, not one" above); Process and Performance are handled separately and don't live in this checklist. The first category is the one that matters most for Product Discernment specifically — evaluating the accuracy, coherence, and relevance of what the AI actually produced, not general code quality trivia:

1. Spec conformance & AI self-report accuracy — does the diff actually match what the spec asked for, and do any claims the coder agent made about its own work (tests added, files changed, "completed") hold up against what's really in the diff? This is where /4ds:discern catches an AI overclaiming or quietly drifting from the task.
2. Assumptions to verify
3. Edge cases & failure modes
4. Security considerations
5. Performance & scale
6. Data / compatibility / migration
7. Testing gaps
8. Rollback & reversibility
9. Dependencies & integration points
10. Observability

Claude fills these in with feature-specific bullets — never generic filler — but never checks them off itself. /4ds:discern helps you work through them; deciding they're actually satisfied is on you.

Customizing for your team

Everything is plain Markdown — fork it:

• Change the spec location: edit the specs/<spec-name>.md path references in skills/brainstorm/SKILL.md, skills/delegate/SKILL.md, skills/refine/SKILL.md, and the template in agents/spec-writer.md.
• Change the outputs location or naming: edit skills/delegate/SKILL.md Steps 10-11 and skills/code/SKILL.md Step 3.
• Add/remove Product checklist categories: edit the template in agents/spec-writer.md (the single source of truth for spec formatting) and the category list in agents/code-reviewer.md.
• Add/remove Process Discernment categories: edit agents/process-reviewer.md.
• Change the Performance Discernment table's dimensions: edit skills/delegate/SKILL.md Step 14.
• Add/remove Task Types: edit the Type vocabulary and classification guidance in agents/spec-writer.md and skills/delegate/SKILL.md Step 8, plus add a matching agent under agents/ if the new type needs one.
• Adjust the task-breakdown size heuristic: skills/brainstorm/SKILL.md, Phase 2.

Design notes / FAQ

Why explicit commands instead of Claude offering this automatically? So it only ever runs when you actually want it to — disable-model- invocation: true on every user-facing skill guarantees Claude can't start one of these flows on its own.

Why doesn't /4ds:brainstorm write real code? Because the point is to keep you writing the code yourself where you've chosen to, and to avoid burning usage on a full implementation before you've even decided you like the approach.

Why is delegation its own command instead of happening during brainstorming? Because who implements a task, and how, is a decision that can be made on its own timeline — you might not know yet when you're still brainstorming, or you might change your mind weeks later. Baking it into brainstorming forces a premature choice. /4ds:delegate keeps Delegation a distinct, deliberate act you can invoke whenever you're actually ready to make that call — including reassigning it later.

Why does delegating to Claude immediately act, instead of just recording the decision? Because splitting "decide" and "do" into two separate commands tangled the decision-making step with implementation details for no real benefit — delegating a task to Claude is asking Claude to do it. Assigning to Human doesn't do the work (that's genuinely yours), but it also doesn't just write a database row and vanish — see the next question.

Why does /4ds:delegate keep talking after assigning a task to me? Because handing you a task and immediately going silent isn't actually useful — you might have questions about the codebase, the approach, or what the spec meant by something. Checking in and discussing before stepping back costs little and catches misunderstandings early, without crossing into doing the work for you.

Why does /4ds:delegate push back on delegating a whole feature at once? Because a large, undecomposed chunk of work handed off in one piece is where things are most likely to go wrong — for a human or for Claude. Smaller, well-scoped tasks are just more reliable to execute and to review. This is a flag, not a hard rule — you can still proceed with the whole thing as one delegation if you've weighed it and still want to.

Why isn't /4ds:code a command anymore? It's still there as a distinct file (skills/code/SKILL.md) — it's just no longer user-invocable (user-invocable: false). It's the internal coding-dispatch process /4ds:delegate reads and follows for Coding-type tasks, kept separate for clarity rather than inlined into delegate itself, but not something you'd ever run standalone anymore since it assumes delegation already happened.

Why is Discernment split into three agents/mechanisms instead of one "review" step? Because Anthropic's own framework splits it that way, and collapsing it into a single code review loses two-thirds of the picture. code-reviewer checking the diff tells you nothing about whether the agent that produced it verified its own work or made unsupported leaps to get there (Process), and nothing about whether the interaction itself — Claude's communication, question-asking, responsiveness — actually served you well (Performance). Keeping them separate means each stays legible and focused instead of one agent trying to judge three different things at once.

Why does process-reviewer run automatically but code-reviewer doesn't? Process Discernment is cheap to always do and easy to lose track of if it's optional — it's checking the work that already just happened, using what's already in context (the agent's own report). Product Discernment (code-reviewer) is heavier and often makes more sense once you've actually decided you want to look closely at something, so it stays on-demand via /4ds:discern.

Why do coder and writer get an isolated worktree but not researcher or analyst? Worktrees matter for agents that write directly to real project files — that's where concurrent-edit collisions could happen. researcher and analyst are read-only against the repo; their output goes to a fresh file elsewhere, so there's nothing to collide with.

Why /4ds:discern and not /4ds:review? Claude Code already ships built-in /review and /code-review skills. Naming ours review would collide with those — discern avoids the clash and names the actual D it supports.

Versioning / Contributing / License

Version 0.1.0. Contributions welcome — open a PR. Licensed under MIT (see LICENSE).