{"slug":"stakeholder-summary","title":"stakeholder-summary","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","platform":"Claude","tags":[],"authorName":"LLM Mart","authorSlug":"llm-mart","score":0,"source":"github","price":null,"verified":false,"createdAt":"2026-10-15T13:12:00.597868Z","repo":{"url":"https://github.com/testdouble/han","stars":303,"forks":24,"license":"MIT","updatedAt":"2026-10-14T20:22:28Z"},"bodyHtml":"<hr>\n<h2>name: \"stakeholder-summary\"\ndescription: &gt;\nProduces a plain-language stakeholder summary from an existing feature specification, for sharing with non-technical\nstakeholders before implementation kicks off. Use when the user wants to draft a stakeholder summary, executive\nsummary, or business summary of a feature spec or PRD. Does not write the spec itself — use plan-a-feature. Does not\nsequence the build into phases — use plan-a-phased-build. Does not produce an implementation plan — use\nplan-implementation.\nargument-hint: \"[path to feature-specification.md, optional: extra context for the summary]\"\nallowed-tools:\nRead, Write, Edit, Glob, Grep, Agent, Bash(find *),\nBash(bash \"$/scripts/han-config-dir.sh\")</h2>\n<h2>Project Context</h2>\n<ul>\n<li>CLAUDE.md: !<code>find . -maxdepth 1 -name \"CLAUDE.md\" -type f</code></li>\n<li>project-discovery.md: !<code>find . -maxdepth 3 -name \"project-discovery.md\" -type f</code></li>\n<li>personal config directory: !<code>bash \"${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh\" 2&gt;/dev/null || echo \"$HOME/.claude\"</code></li>\n<li>project .han/config.md: !<code>cat .han/config.md 2&gt;/dev/null || echo \"\"</code></li>\n</ul>\n<p>As your first action, use the Read tool on <code>.han/config.md</code> inside the <code>personal config directory</code> path above. A read\nthat returns no file is no personal configuration: continue silently. When that file or the <code>project .han/config.md</code>\nprobe supplies content, apply it per <a href=\"../../references/config-rule.md\">config-rule.md</a>, which governs precedence\nbetween the two files, relative-path resolution, and what to do with a file that reads but cannot be used.</p>\n<h2>Operating Principles</h2>\n<ul>\n<li><strong>Plain language only.</strong> The stakeholder summary never contains file paths, line numbers, function or class names,\nlibrary mechanics, database tables, API shapes, or language primitives. Use product-level subsystem names (\"the\ntelematics provider\", \"the customer list\"), user-facing UI vocabulary (badge, popup, list), and behavioral verbs\n(create, edit, update, claim, merge, sync). A non-technical stakeholder must be able to read the document end-to-end\nwithout translation.</li>\n<li><strong>Center the customer, not the system.</strong> Lead with the problem the customer experiences, then the capabilities\nintroduced, then the experience, then the data flow, then what is out of scope, then the questions. The system is the\nmeans, not the subject.</li>\n<li><strong>High level only.</strong> A stakeholder summary is for getting feedback before kickoff. Skip anything that would only\nmatter once implementation has started: schemas, sequencing, file boundaries, test plans, rollout strategy, telemetry.\nIf a detail is only meaningful to engineers, it does not belong in this document.</li>\n<li><strong>Diagrams carry weight.</strong> Use Mermaid for both the user experience flow and the data flow before-and-after. Diagrams\nare not decoration — they replace paragraphs of prose, so they must be readable on their own.</li>\n<li><strong>Open questions are stakeholder-shaped.</strong> The closing questions are framed in customer or product language, not\nengineering language. They ask stakeholders to confirm framing, scope, and trade-offs — not to make technical\ndecisions.</li>\n<li><strong>Apply the shared readability standard.</strong> As it writes and refines the summary, the skill sources the standard by\ninvoking <code>han-communication:readability-guidance</code> and applies it, holding the named audience: the non-technical\nstakeholder. The plain-language rules above are this skill's domain-specific supplement to the shared standard, not a\nreplacement for it. The standard's dedicated <code>han-communication:readability-editor</code> rewrite pass (Step 5) is this\nskill's readability rewrite; it and the standardized self-check (Step 6, Pass B) take the place of the freehand\nplain-language rewrite this skill used to run, so the summary gets one readability review, not two. The standard\ngoverns how the summary reads, never whether a required fact from the spec survives.</li>\n</ul>\n<h1>Stakeholder Summary</h1>\n<h2>Step 1: Resolve the Source and Output Paths</h2>\n<p>Read the user's argument and conversation context. Identify:</p>\n<ol>\n<li><strong>The source specification</strong> — the file the summary will be derived from. Usually a <code>feature-specification.md</code>, but\nmay be a PRD, design doc, or similar. If the user did not name a file, ask in one short message which file to\nsummarize.</li>\n<li><strong>The output path</strong> — <code>stakeholder-summary.md</code> in the <strong>same directory</strong> as the source file. Do not place it anywhere\nelse unless the user explicitly says so.</li>\n<li><strong>Shaping context</strong> — anything the user added about the audience, tone, or emphasis (\"this is going to leadership\",\n\"lean into the customer-trust angle\"). Capture it for use in Steps 3 and 4.</li>\n</ol>\n<p>If <code>stakeholder-summary.md</code> already exists in the target directory, ask the user whether to overwrite, append a\ntimestamp suffix, or stop. Do not silently overwrite.</p>\n<h2>Step 2: Read the Source and Project Context</h2>\n<p>Read the feature specification end-to-end. Then capture:</p>\n<ul>\n<li>The customer problem the feature addresses, in the customer's own words where possible.</li>\n<li>The capabilities the feature introduces, expressed as user-visible actions (not API endpoints, not database changes).\nThis 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\nend users.</li>\n<li>The user experience: what the customer sees, what choices they make, what happens after each choice.</li>\n<li>The current data flow (what happens today) and the new data flow (what will happen after this ships), at the level of\n\"system A sends X to system B\".</li>\n<li>What the spec explicitly says is out of scope, deferred, or handled elsewhere.</li>\n<li>Any open questions the spec already names.</li>\n</ul>\n<p>Read the CLAUDE.md in the project named in the specification and <code>project-discovery.md</code> if present — they may surface\nvocabulary or naming conventions the stakeholder summary should follow.</p>\n<h2>Step 3: Translate Technical Content into Plain Language</h2>\n<p>For every piece of content destined for the summary, apply a translation pass:</p>\n<ul>\n<li><strong>System names generalize one level up.</strong> \"PostgreSQL\" → \"the database\"; \"the FleetCommand API\" → \"the telematics\nprovider\"; \"the React component\" → \"the screen\".</li>\n<li><strong>API and data shapes become user-visible behaviors.</strong> \"POST /units/claim\" → \"Claim it\"; \"PATCH /customers/1/update\nendpoint with [field_name]\" → \"update the existing customer record\".</li>\n<li><strong>Engineering trade-offs become product trade-offs.</strong> \"Eventually consistent reads from the replica\" → not mentioned;\n\"we are not building bulk actions\" → \"Bulk actions. One record at a time for now.\"</li>\n<li><strong>Acronyms and brand names</strong> stay only if a stakeholder would already know them (e.g., the product's own brand,\nwell-known integrations). Otherwise generalize.</li>\n</ul>\n<p>If a piece of content cannot be translated without losing meaning, leave it out. The summary is for feedback on shape\nand direction, not technical correctness.</p>\n<h2>Step 4: Draft the Stakeholder Summary</h2>\n<p>Invoke <code>han-communication:readability-guidance</code> to surface the shared readability standard into your context, then draft\nagainst it. Use the template at\n<a href=\"./references/stakeholder-summary-template.md\"><code>references/stakeholder-summary-template.md</code></a>. Write the file at the\nresolved output path, filling in each section in order:</p>\n<ol>\n<li><strong>Title</strong> — <code># {{Feature Name}} — Stakeholder Summary</code>. Derive the feature name from the source spec's title or H1.</li>\n<li><strong>What problem are we solving?</strong> One or two short paragraphs from the customer's point of view, followed by a short\nbulleted list of the capabilities the feature introduces (each as a bold name plus one sentence in the customer's\nvoice).</li>\n<li><strong>What does this open up?</strong> Four to six bullets naming the outcomes the feature enables — customer confidence, data\ntrust, downstream features unblocked, etc. Each bullet leads with a bold phrase and adds one sentence of why it\nmatters.</li>\n<li><strong>What will the user experience look like?</strong> One short paragraph framing the experience, followed by a Mermaid\n<code>flowchart TD</code> showing the user-facing decision and its branches. Keep nodes short and customer-readable. It is\nacceptable to omit if the change truly has no user interface impact, but this will be rare.</li>\n<li><strong>How does the data flow today vs. after this change?</strong> Mermaid <code>flowchart LR</code> diagrams. <strong>The number of diagrams in\neach subsection — both \"today\" and \"after this change\" — matches the number of meaningfully distinct paths the spec\nactually describes. Never invent paths to hit a template count. Never collapse genuinely distinct paths into one\ndiagram to fit a template count. One today diagram and three \"after this change\" diagrams is correct if that is what\nthe spec needs; two today diagrams and one \"after this change\" diagram is also correct if that is what the spec\nneeds.</strong> Both subsections follow the same shape:</li>\n</ol>\n<ul>\n<li><strong>Today.</strong> One diagram per meaningfully distinct <em>current</em> path, each showing the pain point with <code>style</code> highlighting\non the problem nodes. If there is only one current path worth showing (the common case), produce a single \"Today\"\ndiagram with a one-sentence lead-in above it and no prose block below — the lead-in is enough. If there are two or\nmore current paths, each diagram gets a one-sentence lead-in <em>and</em> a 3 to 5 sentence prose block immediately below\nthat walks the reader through the flow, names the pain point, and names what makes this current path distinct from the\nother current paths.</li>\n<li><strong>After this change.</strong> One diagram per meaningfully distinct <em>new</em> path, highlighting the resulting good state in\ngreen. Every \"after this change\" diagram is followed by a 3 to 5 sentence prose description placed immediately below\nthe diagram, walking the reader through the flow the diagram shows. When there are two or more \"after this change\"\npaths, each prose block must additionally name the trigger or condition that sends the customer down this path rather\nthan the others, and the outcome that differs between paths — a stakeholder reading the prose blocks back-to-back\nshould be able to articulate when each path applies. When there is only one \"after this change\" path, the prose still\nwalks the flow but does not manufacture a contrast against paths that do not exist.</li>\n<li>For all Mermaid charts, do not literally match the template unless the spec aligns. Use a chart that makes sense for\nthe user experience and data flows being described by the feature specification itself. The template contains examples\nonly.</li>\n</ul>\n<ol start=\"6\">\n<li><strong>What is intentionally not in this slice?</strong> Bulleted list of items deliberately excluded. Each item leads with a\nbold phrase and a one-sentence reason or pointer to where it lives instead. Close the section with a single one-line\ncatch-all confirmation prompt directed at stakeholders — something like <em>\"If any of these cuts would block your team,\nflag it before we kick off.\"</em> That one line replaces the per-item \"is this OK?\" question that would otherwise\nduplicate into the next section.</li>\n<li><strong>What we are asking stakeholders.</strong> Three to five open questions that present a real trade-off, framing call, or\nsequencing choice the stakeholder must weigh in on. <strong>A question only earns a spot here if it asks the stakeholder to\nchoose between two or more substantive alternatives, or to confirm framing the document presents as genuinely open.</strong>\nA bare \"is it acceptable that X is deferred?\" — where X is already listed in \"What is intentionally not in this\nslice?\" — is the duplication this rule exists to prevent. Push those back into the prior section's closing prompt.\nQuestions in this section must either:</li>\n</ol>\n<ul>\n<li>present a trade-off with two or more named alternatives (for example, <em>\"Remove the broken button vs. show a\nplaceholder message — which fits the brand better?\"</em>), or</li>\n<li>confirm framing or scope that is not already settled by the body of the document (for example, <em>\"Are we right to treat\nthis as a v1 for desktop users only, or should mobile parity be part of v1?\"</em>), or</li>\n<li>surface an open question the source spec itself names as unresolved. Frame every question so a non-technical reader\ncan answer it, and connect each one to a section above it so the reader can see what it follows from.</li>\n</ul>\n<p><strong>Write the file in one pass once the content is ready</strong> — the document is short enough that incremental saves are\nunnecessary. After writing, read it back end-to-end and rewrite any sentence that still leaks implementation detail.</p>\n<h2>Step 5: Readability Rewrite</h2>\n<p>Dispatch <code>han-communication:readability-editor</code> over the drafted summary to rewrite it for the non-technical stakeholder\nagainst the shared readability standard, preserving every fact from the source spec. This is the skill's dedicated\nreadability rewrite; it replaces the freehand plain-language rewrite the skill used to do at the end of Step 4.</p>\n<ul>\n<li><strong><code>han-communication:readability-editor</code></strong> — rewrite the summary at the output path against the shared readability\nstandard for the named audience (the non-technical stakeholder), preserving every fact: every capability, exclusion,\nquantity, named system-in-customer-terms, and stated condition survives with its precision intact. It operates on\n<strong>prose regions only</strong>: it does not touch the Mermaid diagram bodies (their customer-readable node and edge labels are\nchecked separately in Step 6, Pass C), and it leaves no engineering artifacts behind. Pass it the output-file path and\nthe named audience; the editor reads han-communication's own canonical rule, so pass no rule path. It rewrites the\nfile in place and returns a rubric verdict and a fact-preservation ledger.</li>\n</ul>\n<p>Apply its rewrite. If the editor reports it could not preserve a fact while satisfying a criterion, keep the fact.</p>\n<h2>Step 6: Self-Check Before Presenting</h2>\n<p>Run three passes before reporting the summary as done. Each pass has a single focus, and <strong>each pass begins with a fresh\nRead of the output file from disk</strong> — do not check against working memory or the draft you held while writing. The Read\ntool call is required, not optional. Working memory drifts from what actually landed on disk; only the file contents\nmatter.</p>\n<h3>Pass A: Internal-consistency / contradiction check</h3>\n<p><strong>First, use the Read tool to load the output file from disk.</strong> Then list every load-bearing claim the document makes —\ncapability included, capability deferred, behavior described in a diagram, prose narrative below a diagram, item under\n\"What is intentionally not in this slice\", trade-off or framing call in \"What we are asking stakeholders\". For every\npair of claims, ask: does claim X assert something that claim Y denies or implies the opposite of? Pay special attention\nto:</p>\n<ul>\n<li><strong>Diagram vs. exclusion.</strong> A capability shown in any data-flow diagram (or its prose block below) that \"What is\nintentionally not in this slice\" says is deferred, and vice versa. This is the most common form of contradiction: a\ndiagram walks the customer through a step that uses a capability the exclusion section says is not in the slice. The\nfix is almost always to disambiguate the wording on one side — clarifying that the diagram is showing a narrower\ncapability than the exclusion appears to forbid, or vice versa.</li>\n<li><strong>UX vs. data flow.</strong> A behavior in the user-experience flowchart that contradicts a behavior in any data-flow\ndiagram, or vice versa.</li>\n<li><strong>Outcomes vs. exclusion.</strong> A capability named in \"What does this open up?\" that \"What is intentionally not in this\nslice\" says is deferred.</li>\n<li><strong>Diagram vs. diagram.</strong> An assumption in the prose under one diagram that conflicts with an assumption in the prose\nunder another diagram.</li>\n<li><strong>Vocabulary collisions.</strong> The same term used to mean two different things in different sections (for example, \"share\"\nused both for <em>sending a URL another user can open</em> and for <em>publishing a view to your whole organization</em>), or\ndifferent terms used for the same thing in different sections.</li>\n</ul>\n<p>For every contradiction found, take an evidence-based approach to resolving it:</p>\n<ol>\n<li><strong>Re-read the source specification</strong> identified in Step 1. The spec is the authoritative source for what the feature\ndoes and does not do. Most contradictions in the summary are translation errors — the spec is internally consistent\nand the summary mistranslated one side.</li>\n<li><strong>If the spec resolves the contradiction:</strong> edit the summary so both sides match the spec. If the apparent\ncontradiction is actually a terminology collision (the same word covering two distinct concepts), disambiguate the\nwording — typically by renaming one usage to a more specific term that the source spec, its CLAUDE.md, or its\nproject-discovery vocabulary already supports. Record in working memory which contradiction was resolved and how, so\nthe same disambiguation can be applied uniformly across every section.</li>\n<li><strong>If the spec does not resolve the contradiction</strong> — because the spec is silent on the point, the spec itself is\ninternally inconsistent, or the resolution depends on a judgment call only the user can make — <strong>stop and ask the\nuser.</strong> Do not guess. Use <code>AskUserQuestion</code> to surface a structured ask containing:</li>\n</ol>\n<ul>\n<li><strong>A plain-language description of the contradiction</strong>, naming both sides explicitly (\"Section X says A; Section Y says\nB; these conflict because…\"). Quote the actual phrasing from each section.</li>\n<li><strong>Two to four resolution options.</strong> Typical patterns: keep A and rewrite B; keep B and rewrite A; reconcile by\ndisambiguating terminology and using the disambiguated terms in both sections; move the contradicting capability into\n\"What is intentionally not in this slice\" and remove it from elsewhere.</li>\n<li><strong>Your recommended option, marked clearly,</strong> with a one-sentence reason grounded in the source spec, the project's\nconventions, or the stakeholder framing the user provided in Step 1. The recommendation must be a concrete option from\nthe list above, not a fresh suggestion.</li>\n<li><strong>A direct request that the user pick which resolution to apply.</strong></li>\n</ul>\n<p>After applying any contradiction-driven edits, Read the file from disk again before continuing. Pass B and Pass C must\nrun against the post-fix contents.</p>\n<h3>Pass B: Standardized readability self-check</h3>\n<p><strong>First, use the Read tool to load the output file from disk.</strong> The readability-editor already rewrote the summary in\nStep 5; this pass confirms the standardized self-check (the shared standard is in your context from\n<code>han-communication:readability-guidance</code>) holds, over the document's prose regions only — never inside the Mermaid\ndiagram bodies. Apply any fix with Edit.</p>\n<p>Run the readability rule's standardized self-check, which is already in your context from the <code>readability-guidance</code>\ninvocation above. Correct every failure before presenting. Its fidelity criterion is not optional: the standard governs\nhow the content is said, and drops a required fact only when the reader asked for less and losing it would not change\nwhat they do next.</p>\n<p>Three things are this skill's own, layered on top of that check:</p>\n<ul>\n<li>The opening line states the customer problem, before any capability.</li>\n<li>The fidelity criterion covers every capability, exclusion, quantity, named entity, and stated condition or qualifier\ncarried over from the source spec.</li>\n<li>The shared vocabulary blocklist is authoritative, and this domain-specific list sits on top of it for a\nnon-technical stakeholder:\n<ul>\n<li><strong>No engineering artifacts.</strong> No file paths, function names, class names, database tables or columns, API\nendpoints, HTTP verbs, library or framework names, environment variables, queue or topic names, or language\nprimitives.</li>\n<li><strong>No engineering hedges.</strong> No \"eventually consistent\", \"idempotent\", \"race condition\", \"backfill\", \"migration\",\n\"schema\", \"payload\", \"request/response\", \"stateless\", \"async\", \"webhook\", \"polling vs. push\", or similar. If a\nconcept like this is load-bearing, restate it as a user-visible behavior or omit it.</li>\n<li><strong>No leftover scaffolding.</strong> Template placeholders, TODOs, \"TBD\", or example text from the template that was not\nreplaced with real content.</li>\n<li><strong>Closing questions are stakeholder-answerable.</strong> A non-technical reader can give a real answer without asking an\nengineer what the question means.</li>\n</ul>\n</li>\n</ul>\n<p>If Pass B required any edits, apply them with Edit, then <strong>Read the file again from disk</strong> before starting Pass C. The\nPass C read-through must run against the post-fix contents, not your memory of what you intended to fix.</p>\n<h3>Pass C: Reading-order and progressive-disclosure check</h3>\n<p><strong>First, use the Read tool to load the output file from disk again</strong> — even if Pass B required no edits. This re-load is\nwhat makes Pass C an actual third pass rather than a continuation of Pass B's attention. Then read the document straight\nthrough, top to bottom, as someone arriving cold. Verify the document builds on itself rather than assuming context from\na later section:</p>\n<ul>\n<li><strong>The opening establishes the customer problem before naming any capability.</strong> A reader should know <em>who is hurting\nand why</em> before they see <em>what we are building</em>.</li>\n<li><strong>Each section uses only vocabulary the reader has already encountered.</strong> A noun that appears in the data-flow diagram\nshould have been introduced in the problem or capabilities sections — not first defined inside the diagram. Acronyms\nand product-internal names appear only if a stakeholder would already know them; otherwise generalize one level up\n(\"the telematics provider\", \"the customer list\").</li>\n<li><strong>Diagrams are readable on their own.</strong> Node labels and edge labels tell the story without requiring the surrounding\nprose. A reader who only skims the diagrams should still get the shape of the change.</li>\n<li><strong>Diagram counts match the spec, not the template.</strong> Both \"today\" and \"after this change\" subsections have one diagram\nper meaningfully distinct path in the spec — no padding to two, no collapsing distinct paths into one. A spec with one\ncurrent path and three new paths should produce 1 today diagram + 3 after-this-change diagrams. A spec with two\ncurrent paths and one new path should produce 2 today diagrams + 1 after-this-change diagram.</li>\n<li><strong>Every \"after this change\" diagram has a 3-5 sentence prose block immediately below it.</strong> The block walks through the\nflow. When two or more \"after this change\" paths exist, each block also names what triggers this path and what outcome\ndiffers from the others, so a stakeholder reading the blocks back-to-back can articulate when each path applies. When\nonly one \"after this change\" path exists, the block walks the flow without manufacturing a contrast against absent\nsiblings.</li>\n<li><strong>The \"Today\" subsection scales the same way.</strong> A single today diagram needs only its one-sentence lead-in — no prose\nblock below. Two or more today diagrams each get a 3-5 sentence prose block below that walks the flow, names the pain\npoint, and names what makes this current path distinct from the other current paths.</li>\n<li><strong>The \"today vs. after this change\" pairing is obvious.</strong> The before-and-after diagrams sit close enough together that\nthe contrast is visible without scrolling back and forth.</li>\n<li><strong>The \"intentionally not in this slice\" list comes after the reader understands what <em>is</em> in the slice.</strong> Out-of-scope\nonly makes sense once in-scope is concrete.</li>\n<li><strong>The closing questions follow from the body.</strong> Each question should connect to a specific section above it — not\nintroduce a new topic the document never mentioned.</li>\n<li><strong>No question in \"What we are asking\" restates an item from \"What is intentionally not in this slice\".</strong> For each\nclosing question, find the exclusion item it would map to. If the question is essentially <em>\"is this exclusion OK?\"</em>\nwith no new trade-off or alternative attached, remove it — the closing one-liner at the bottom of \"What is\nintentionally not in this slice\" already collects that confirmation. Every remaining question in \"What we are asking\"\nmust present a named alternative, an unresolved framing call, or an open question the spec itself names.</li>\n</ul>\n<p>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\nA edit changes content that Pass B or Pass C already cleared, re-run those passes against the new content —\ncontradiction fixes can re-introduce language or reading-order issues that the earlier passes caught. Do not present a\nsummary that fails Pass A or Pass B — a stakeholder who reads a contradiction or has to ask \"what does X mean?\" has\nalready lost trust in the document.</p>\n<h2>Step 7: Present the Summary</h2>\n<p>Summarize for the user in one short message:</p>\n<ul>\n<li>The output file path.</li>\n<li>The number of capabilities introduced, the number of \"what this opens up\" outcomes, and the number of open questions.</li>\n<li>The next concrete action — typically \"review the summary, especially the open questions section, and share it with\nstakeholders, or tell me what to tighten before you do\".</li>\n</ul>\n<p>Ask whether the user wants to refine wording, add or remove a question, or consider the summary ready to share.</p>\n","files":[{"path":"references/stakeholder-summary-template.md","sizeBytes":5267,"isText":true},{"path":"SKILL.md","sizeBytes":25173,"isText":true}],"reviewScore":null,"reviewSummary":null,"trust":{"provenance":"trusted-source-unreviewed","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow.","bodySource":null},"bodyLocked":false,"purchaseUrl":null,"sourceUrl":null,"report":{"provenance":"trusted-source-unreviewed","screen":{"ran":true,"outcome":"clean","suspicious":0,"notes":0,"hiddenCharacters":false},"virusScan":{"engine":"clamav","status":"clean","scannedAt":"2026-10-15T13:12:49.935997Z","sha256":"C112C4076D3C1B009C675DF2DE1CADB09437C4181E1905857862928720D1ADD6","sizeBytes":11536},"review":null,"source":{"repositoryUrl":"https://github.com/testdouble/han","path":"han-reporting/skills/stakeholder-summary","license":"MIT","commit":"abba73a773528905a8f3d15956029394746e5c7f","subtreeSha":"613FDAA25CCA4D89AE4CF78E97894322B2D3A43C857319DE3CE88C1AEDB4C5DE","lastSyncedAt":"2026-10-15T13:11:53.672149Z"},"reviewedAt":"2026-10-15T13:14:21.706712Z","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow."},"install":[{"target":"skills-cli","command":"npx skills add https://github.com/testdouble/han/tree/main/han-reporting/skills/stakeholder-summary"},{"target":"claude-code","command":"claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install testdouble-han@llmmart"},{"target":"git","command":"git clone https://github.com/testdouble/han.git"}]}