stakeholder-summary
Produces a plain-language stakeholder summary from an existing feature specification, for sharing with non-technical stakeholders before implementation kicks off. Use when the user wants to draft a stakeholder summary, executive summary, or business summary of a feature spec or PRD. Does not write the spec itself — use plan-a-feature. Does not sequence the build into phases — use plan-a-phased-build. Does not produce an implementation plan — use plan-implementation.
npx skills add testdouble/han --skill stakeholder-summary --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Produces a plain-language stakeholder summary from an existing feature specification, for sharing with non-technical stakeholders before implementation kicks off. Use when the user wants to draft a stakeholder summary, executive summary, or business summary of a feature spec or PRD. Does not write the spec itself — use plan-a-feature. Does not sequence the build into phases — use plan-a-phased-build. Does not produce an implementation plan — use plan-implementation.
How it works
Follows a multi-step process that starts by identifying the source specification and the output path (stakeholder-summary.md in the same directory as the source). It then reads the source spec to extract customer problems, capabilities in user-visible terms, the user experience, and current vs. new data flows. It translates technical content into plain language, generalizes system and API references, and drafts a stakeholder-ready summary using a readability guidance process. The draft is written to the resolved output path and then rewritten by a dedicated readability editor. Finally, three self-check passes verify consistency, diagram accuracy, and alignment with the summary’s intent.
When to use it
Use when the user needs a stakeholder-friendly summary of a feature spec or PRD to share with leadership or non-technical stakeholders before kickoff.
What it can touch
The skill uses the tool set Read, Write, Edit, Glob, Grep, Agent, Bash(find *). It reads the source specification and writes the stakeholder-summary.md in the same directory as the source, following the specified output path rules.
Caveats
The skill excludes technical details (file paths, line numbers, APIs, database schemas, or language primitives) and emphasizes plain-language descriptions. It explicitly directs users to other skills for writing the actual spec, phased builds, or implementation plans. License: MIT.
## Project Context - CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f` - project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f` - personal config directory: !`echo "${CLAUDE_CONFIG_DIR:-$HOME/.claude}"` - project .han/config.md: !`cat .han/config.md 2>/dev/null || echo ""` As your first action, use the Read tool on `.han/config.md` inside the `personal config directory` path above. A read that returns no file is no personal configuration: continue silently. When that file or the `project .han/config.md` probe supplies content, apply it per [config-rule.md](../../references/config-rule.md), which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used. ## Operating Principles - **Plain language only.** The stakeholder summary never contains file paths, line numbers, function or class names, library mechanics, database tables, API shapes, or language primitives. Use product-level subsystem names ("the telematics provider", "the customer list"), user-facing UI vocabulary (badge, popup, list), and behavioral verbs (create, edit, update, claim, merge, sync). A non-technical stakeholde
- Project Context
- Operating Principles
- Step 1: Resolve the Source and Output Paths
- Step 2: Read the Source and Project Context
- Step 3: Translate Technical Content into Plain Language
- Step 4: Draft the Stakeholder Summary
- Step 5: Readability Rewrite
- Step 6: Self-Check Before Presenting
- Pass A: Internal-consistency / contradiction check
- Pass B: Standardized readability self-check
- Pass C: Reading-order and progressive-disclosure check
- Step 7: Present the Summary
What does the stakeholder-summary skill do?
Produces a plain-language stakeholder summary from an existing feature specification, for sharing with non-technical stakeholders before implementation kicks off. Use when the user wants to draft a stakeholder summary, executive summary, or business summary of a feature spec or PRD. Does not write the spec itself — use plan-a-feature. Does not sequence the build into phases — use plan-a-phased-build. Does not produce an implementation plan — use plan-implementation.
How do I install it?
Run `npx skills add testdouble/han --skill stakeholder-summary --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From testdouble/han, a repository with 154 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.