stakeholder-summary

Name: stakeholder-summary
Author: testdouble

122stars12forks

How to install stakeholder-summary?

testdouble/han/stakeholder-summary

$npx -y skills add testdouble/han --skill stakeholder-summary

Installs into the current project.

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 P

Files · 1

View on GitHub

SKILL.md

1	## Project Context
2
3	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
4	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
5
6	## Operating Principles
7
8	- 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 stakeholder must be able to read the document end-to-end without translation.
9	- Center the customer, not the system. Lead with the problem the customer experiences, then the capabilities introduced, then the experience, then the data flow, then what is out of scope, then the questions. The system is the means, not the subject.
10	- High level only. A stakeholder summary is for getting feedback before kickoff. Skip anything that would only matter once implementation has started: schemas, sequencing, file boundaries, test plans, rollout strategy, telemetry. If a detail is only meaningful to engineers, it does not belong in this document.
11	- Diagrams carry weight. Use Mermaid for both the user experience flow and the data flow before-and-after. Diagrams are not decoration — they replace paragraphs of prose, so they must be readable on their own.
12	- Open questions are stakeholder-shaped. The closing questions are framed in customer or product language, not engineering language. They ask stakeholders to confirm framing, scope, and trade-offs — not to make technical decisions.
13	- Apply the shared readability standard. As it writes and refines the summary, the skill loads and applies [`../../references/readability-rule.md`](../../references/readability-rule.md), holding the named audience: the non-technical stakeholder. The plain-language rules above are this skill's domain-specific supplement to the shared standard, not a replacement for it. The standard's dedicated `han-core:readability-editor` rewrite pass (Step 5) is this skill's readability rewrite; it and the standardized self-check (Step 6, Pass B) take the place of the freehand plain-language rewrite this skill used to run, so the summary gets one readability review, not two. The standard governs how the summary reads, never whether a required fact from the spec survives.
14
15	# Stakeholder Summary
16
17	## Step 1: Resolve the Source and Output Paths
18
19	Read the user's argument and conversation context. Identify:
20
21	1. The source specification — the file the summary will be derived from. Usually a `feature-specification.md`, but may be a PRD, design doc, or similar. If the user did not name a file, ask in one short message which file to summarize.
22	2. The output path — `stakeholder-summary.md` in the same directory as the source file. Do not place it anywhere else unless the user explicitly says so.
23	3. Shaping context — anything the user added about the audience, tone, or emphasis ("this is going to leadership", "lean into the customer-trust angle"). Capture it for use in Steps 3 and 4.
24
25	If `stakeholder-summary.md` already exists in the target directory, ask the user whether to overwrite, append a timestamp suffix, or stop. Do not silently overwrite.
26
27	## Step 2: Read the Source and Project Context
28
29	Read the feature specification end-to-end. Then capture:
30
31	- The customer problem the feature addresses, in the customer's own words where possible.
32	- The capabilities the feature introduces, expressed as user-visible actions (not API endpoints, not database changes). This is true even if the outcome is an API and not user visible yet. We want to provide what the spec will do for our end users.
33	- The user experience: what the customer sees, what choices they make, what happens after each choice.
34	- The current data flow (what happens today) and the new data flow (what will happen after this ships), at the level of "system A sends X to system B".
35	- What the spec explicitly says is out of scope, deferred, or handled elsewhere.
36	- Any open questions the spec already names.
37
38	Read the CLAUDE.md in the project named in the specification and `project-discovery.md` if present — they may surface

People who liked this also viewed

6 picks

Type

stakeholder-summary

122stars12forks

View on GitHub

How to install stakeholder-summary?

testdouble/han/stakeholder-summary

$npx -y skills add testdouble/han --skill stakeholder-summary

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Project Context
2
3	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
4	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
5
6	## Operating Principles
7
8	- 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 stakeholder must be able to read the document end-to-end without translation.
9	- Center the customer, not the system. Lead with the problem the customer experiences, then the capabilities introduced, then the experience, then the data flow, then what is out of scope, then the questions. The system is the means, not the subject.
10	- High level only. A stakeholder summary is for getting feedback before kickoff. Skip anything that would only matter once implementation has started: schemas, sequencing, file boundaries, test plans, rollout strategy, telemetry. If a detail is only meaningful to engineers, it does not belong in this document.
11	- Diagrams carry weight. Use Mermaid for both the user experience flow and the data flow before-and-after. Diagrams are not decoration — they replace paragraphs of prose, so they must be readable on their own.
12	- Open questions are stakeholder-shaped. The closing questions are framed in customer or product language, not engineering language. They ask stakeholders to confirm framing, scope, and trade-offs — not to make technical decisions.
13	- Apply the shared readability standard. As it writes and refines the summary, the skill loads and applies [`../../references/readability-rule.md`](../../references/readability-rule.md), holding the named audience: the non-technical stakeholder. The plain-language rules above are this skill's domain-specific supplement to the shared standard, not a replacement for it. The standard's dedicated `han-core:readability-editor` rewrite pass (Step 5) is this skill's readability rewrite; it and the standardized self-check (Step 6, Pass B) take the place of the freehand plain-language rewrite this skill used to run, so the summary gets one readability review, not two. The standard governs how the summary reads, never whether a required fact from the spec survives.
14
15	# Stakeholder Summary
16
17	## Step 1: Resolve the Source and Output Paths
18
19	Read the user's argument and conversation context. Identify:
20
21	1. The source specification — the file the summary will be derived from. Usually a `feature-specification.md`, but may be a PRD, design doc, or similar. If the user did not name a file, ask in one short message which file to summarize.
22	2. The output path — `stakeholder-summary.md` in the same directory as the source file. Do not place it anywhere else unless the user explicitly says so.
23	3. Shaping context — anything the user added about the audience, tone, or emphasis ("this is going to leadership", "lean into the customer-trust angle"). Capture it for use in Steps 3 and 4.
24
25	If `stakeholder-summary.md` already exists in the target directory, ask the user whether to overwrite, append a timestamp suffix, or stop. Do not silently overwrite.
26
27	## Step 2: Read the Source and Project Context
28
29	Read the feature specification end-to-end. Then capture:
30
31	- The customer problem the feature addresses, in the customer's own words where possible.
32	- The capabilities the feature introduces, expressed as user-visible actions (not API endpoints, not database changes). This is true even if the outcome is an API and not user visible yet. We want to provide what the spec will do for our end users.
33	- The user experience: what the customer sees, what choices they make, what happens after each choice.
34	- The current data flow (what happens today) and the new data flow (what will happen after this ships), at the level of "system A sends X to system B".
35	- What the spec explicitly says is out of scope, deferred, or handled elsewhere.
36	- Any open questions the spec already names.
37
38	Read the CLAUDE.md in the project named in the specification and `project-discovery.md` if present — they may surface

People who liked this also viewed

6 picks

Type