stakeholder-summary — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited stakeholder-summary (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
find . -maxdepth 1 -name "CLAUDE.md" -type ffind . -maxdepth 3 -name "project-discovery.md" -type fbash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"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, which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.
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.
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.
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.
are not decoration — they replace paragraphs of prose, so they must be readable on their own.
engineering language. They ask stakeholders to confirm framing, scope, and trade-offs — not to make technical decisions.
invoking han-communication:readability-guidance and applies it, 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-communication: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.
Read the user's argument and conversation context. Identify:
feature-specification.md, butmay be a PRD, design doc, or similar. If the user did not name a file, ask in one short message which file to summarize.
stakeholder-summary.md in the same directory as the source file. Do not place it anywhereelse unless the user explicitly says so.
"lean into the customer-trust angle"). Capture it for use in Steps 3 and 4.
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.
Read the feature specification end-to-end. Then capture:
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.
"system A sends X to system B".
Read the CLAUDE.md in the project named in the specification and project-discovery.md if present — they may surface vocabulary or naming conventions the stakeholder summary should follow.
For every piece of content destined for the summary, apply a translation pass:
provider"; "the React component" → "the screen".
endpoint with [field_name]" → "update the existing customer record".
"we are not building bulk actions" → "Bulk actions. One record at a time for now."
well-known integrations). Otherwise generalize.
If a piece of content cannot be translated without losing meaning, leave it out. The summary is for feedback on shape and direction, not technical correctness.
Invoke han-communication:readability-guidance to surface the shared readability standard into your context, then draft against it. Use the template at references/stakeholder-summary-template.md. Write the file at the resolved output path, filling in each section in order:
# {{Feature Name}} — Stakeholder Summary. Derive the feature name from the source spec's title or H1.bulleted list of the capabilities the feature introduces (each as a bold name plus one sentence in the customer's voice).
trust, downstream features unblocked, etc. Each bullet leads with a bold phrase and adds one sentence of why it matters.
flowchart TD showing the user-facing decision and its branches. Keep nodes short and customer-readable. It is acceptable to omit if the change truly has no user interface impact, but this will be rare.
flowchart LR diagrams. **The number of diagrams ineach subsection — both "today" and "after this change" — matches the number of meaningfully distinct paths the spec actually describes. Never invent paths to hit a template count. Never collapse genuinely distinct paths into one diagram to fit a template count. One today diagram and three "after this change" diagrams is correct if that is what the spec needs; two today diagrams and one "after this change" diagram is also correct if that is what the spec needs.** Both subsections follow the same shape:
style highlightingon the problem nodes. If there is only one current path worth showing (the common case), produce a single "Today" diagram with a one-sentence lead-in above it and no prose block below — the lead-in is enough. If there are two or more current paths, each diagram gets a one-sentence lead-in _and_ a 3 to 5 sentence prose block immediately below that walks the reader through the flow, names the pain point, and names what makes this current path distinct from the other current paths.
green. Every "after this change" diagram is followed by a 3 to 5 sentence prose description placed immediately below the diagram, walking the reader through the flow the diagram shows. When there are two or more "after this change" paths, each prose block must additionally name the trigger or condition that sends the customer down this path rather than the others, and the outcome that differs between paths — a stakeholder reading the prose blocks back-to-back should be able to articulate when each path applies. When there is only one "after this change" path, the prose still walks the flow but does not manufacture a contrast against paths that do not exist.
the user experience and data flows being described by the feature specification itself. The template contains examples only.
bold phrase and a one-sentence reason or pointer to where it lives instead. Close the section with a single one-line catch-all confirmation prompt directed at stakeholders — something like _"If any of these cuts would block your team, flag it before we kick off."_ That one line replaces the per-item "is this OK?" question that would otherwise duplicate into the next section.
sequencing choice the stakeholder must weigh in on. A question only earns a spot here if it asks the stakeholder to choose between two or more substantive alternatives, or to confirm framing the document presents as genuinely open. A bare "is it acceptable that X is deferred?" — where X is already listed in "What is intentionally not in this slice?" — is the duplication this rule exists to prevent. Push those back into the prior section's closing prompt. Questions in this section must either:
placeholder message — which fits the brand better?"_), or
this as a v1 for desktop users only, or should mobile parity be part of v1?"_), or
can answer it, and connect each one to a section above it so the reader can see what it follows from.
Write the file in one pass once the content is ready — the document is short enough that incremental saves are unnecessary. After writing, read it back end-to-end and rewrite any sentence that still leaks implementation detail.
Dispatch han-communication:readability-editor over the drafted summary to rewrite it for the non-technical stakeholder against the shared readability standard, preserving every fact from the source spec. This is the skill's dedicated readability rewrite; it replaces the freehand plain-language rewrite the skill used to do at the end of Step 4.
standard for the named audience (the non-technical stakeholder), preserving every fact: every capability, exclusion, quantity, named system-in-customer-terms, and stated condition survives with its precision intact. It operates on prose regions only: it does not touch the Mermaid diagram bodies (their customer-readable node and edge labels are checked separately in Step 6, Pass C), and it leaves no engineering artifacts behind. Pass it the output-file path and the named audience; the editor reads han-communication's own canonical rule, so pass no rule path. It rewrites the file in place and returns a rubric verdict and a fact-preservation ledger.
Apply its rewrite. If the editor reports it could not preserve a fact while satisfying a criterion, keep the fact.
Run three passes before reporting the summary as done. Each pass has a single focus, and each pass begins with a fresh Read of the output file from disk — do not check against working memory or the draft you held while writing. The Read tool call is required, not optional. Working memory drifts from what actually landed on disk; only the file contents matter.
First, use the Read tool to load the output file from disk. Then list every load-bearing claim the document makes — capability included, capability deferred, behavior described in a diagram, prose narrative below a diagram, item under "What is intentionally not in this slice", trade-off or framing call in "What we are asking stakeholders". For every pair of claims, ask: does claim X assert something that claim Y denies or implies the opposite of? Pay special attention to:
intentionally not in this slice" says is deferred, and vice versa. This is the most common form of contradiction: a diagram walks the customer through a step that uses a capability the exclusion section says is not in the slice. The fix is almost always to disambiguate the wording on one side — clarifying that the diagram is showing a narrower capability than the exclusion appears to forbid, or vice versa.
diagram, or vice versa.
slice" says is deferred.
under another diagram.
used both for _sending a URL another user can open_ and for _publishing a view to your whole organization_), or different terms used for the same thing in different sections.
For every contradiction found, take an evidence-based approach to resolving it:
does and does not do. Most contradictions in the summary are translation errors — the spec is internally consistent and the summary mistranslated one side.
contradiction is actually a terminology collision (the same word covering two distinct concepts), disambiguate the wording — typically by renaming one usage to a more specific term that the source spec, its CLAUDE.md, or its project-discovery vocabulary already supports. Record in working memory which contradiction was resolved and how, so the same disambiguation can be applied uniformly across every section.
internally inconsistent, or the resolution depends on a judgment call only the user can make — stop and ask the user. Do not guess. Use AskUserQuestion to surface a structured ask containing:
B; these conflict because…"). Quote the actual phrasing from each section.
disambiguating terminology and using the disambiguated terms in both sections; move the contradicting capability into "What is intentionally not in this slice" and remove it from elsewhere.
conventions, or the stakeholder framing the user provided in Step 1. The recommendation must be a concrete option from the list above, not a fresh suggestion.
After applying any contradiction-driven edits, Read the file from disk again before continuing. Pass B and Pass C must run against the post-fix contents.
First, use the Read tool to load the output file from disk. The readability-editor already rewrote the summary in Step 5; this pass confirms the standardized self-check (the shared standard is in your context from han-communication:readability-guidance) holds, over the document's prose regions only — never inside the Mermaid diagram bodies. Apply any fix with Edit.
Run the readability rule's standardized self-check, which is already in your context from the readability-guidance invocation above. Correct every failure before presenting. Its fidelity criterion is not optional: the standard governs how the content is said, and drops a required fact only when the reader asked for less and losing it would not change what they do next.
Three things are this skill's own, layered on top of that check:
carried over from the source spec.
non-technical stakeholder:
endpoints, HTTP verbs, library or framework names, environment variables, queue or topic names, or language primitives.
"schema", "payload", "request/response", "stateless", "async", "webhook", "polling vs. push", or similar. If a concept like this is load-bearing, restate it as a user-visible behavior or omit it.
replaced with real content.
engineer what the question means.
If Pass B required any edits, apply them with Edit, then Read the file again from disk before starting Pass C. The Pass C read-through must run against the post-fix contents, not your memory of what you intended to fix.
First, use the Read tool to load the output file from disk again — even if Pass B required no edits. This re-load is what makes Pass C an actual third pass rather than a continuation of Pass B's attention. Then read the document straight through, top to bottom, as someone arriving cold. Verify the document builds on itself rather than assuming context from a later section:
and why_ before they see _what we are building_.
should have been introduced in the problem or capabilities sections — not first defined inside the diagram. Acronyms and product-internal names appear only if a stakeholder would already know them; otherwise generalize one level up ("the telematics provider", "the customer list").
prose. A reader who only skims the diagrams should still get the shape of the change.
per meaningfully distinct path in the spec — no padding to two, no collapsing distinct paths into one. A spec with one current path and three new paths should produce 1 today diagram + 3 after-this-change diagrams. A spec with two current paths and one new path should produce 2 today diagrams + 1 after-this-change diagram.
flow. When two or more "after this change" paths exist, each block also names what triggers this path and what outcome differs from the others, so a stakeholder reading the blocks back-to-back can articulate when each path applies. When only one "after this change" path exists, the block walks the flow without manufacturing a contrast against absent siblings.
block below. Two or more today diagrams each get a 3-5 sentence prose block below that walks the flow, names the pain point, and names what makes this current path distinct from the other current paths.
the contrast is visible without scrolling back and forth.
only makes sense once in-scope is concrete.
introduce a new topic the document never mentioned.
closing question, find the exclusion item it would map to. If the question is essentially _"is this exclusion OK?"_ with no new trade-off or alternative attached, remove it — the closing one-liner at the bottom of "What is intentionally not in this slice" already collects that confirmation. Every remaining question in "What we are asking" must present a named alternative, an unresolved framing call, or an open question the spec itself names.
If any check in any pass fails, fix it with Edit and Read the file again before re-running the affected pass. If a Pass A edit changes content that Pass B or Pass C already cleared, re-run those passes against the new content — contradiction fixes can re-introduce language or reading-order issues that the earlier passes caught. Do not present a summary that fails Pass A or Pass B — a stakeholder who reads a contradiction or has to ask "what does X mean?" has already lost trust in the document.
Summarize for the user in one short message:
stakeholders, or tell me what to tighten before you do".
Ask whether the user wants to refine wording, add or remove a question, or consider the summary ready to share.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.