stakeholder-summary
SolidProduces 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.
Install
Quality Score: 88/100
Skill Content
Details
- Author
- testdouble
- Repository
- testdouble/han
- Created
- 3 weeks ago
- Last Updated
- today
- Language
- Shell
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
plan-implementation
Builds a feature implementation plan from an existing feature specification (or equivalent context) through a project-manager-led team conversation. Use when the user wants to plan how to implement, build, deliver, or ship a feature that has already been specified — including requests like "plan the implementation of X", "how do we build this", "turn this spec into an implementation plan", or "figure out how we'd actually ship this". Launches a team of specialist sub-agents sized to the feature, always including `project-manager` as coordinator and `junior-developer` as generalist stress-tester, and iterates rounds of discussion until the project-manager confirms the plan is ready or only user input remains. Produces three cross-referenced files in the same folder as the source feature specification: feature-implementation-plan.md (the primary plan), implementation-decision-log.md (every committed decision with rationale and evidence), and implementation-iteration-history.md (round-by-round record of speciali
plan-a-feature
Builds a feature specification from scratch through a relentless, evidence-based interview that walks the design tree decision-by-decision, resolving dependencies as it goes. Use when the user wants to plan, design, scope, specify, or flesh out a new feature, capability, or system behavior before implementation — including requests like "help me plan X", "spec out this feature", "design the Y flow", or "let's figure out what it should do". Explores the codebase, project documentation, coding standards, and ADRs to resolve questions before asking the user, and always offers a recommended answer when questions must be surfaced. Produces a feature-specification.md focused on system behaviors, coordinations, processes, and user interactions — not implementation detail. Does not refine or stress-test an existing plan — use iterative-plan-review. Does not investigate bugs or failures — use investigate. Does not analyze existing architecture — use architectural-analysis. Does not document already-built features — us
plan-a-phased-build
Splits a body of context into a sequence of vertical-slice build phases where each phase is independently demonstrable to a real user and each builds on the work of the previous. Use when the user wants to plan, sequence, phase, slice, break down, or order the build of a feature, capability, system, or initiative — including requests like "split this into phases", "what should we build first", "create a build plan", "phase this work", "turn this into vertical slices", "outline the order of delivery", or "what's our roadmap". Accepts any source of context — gap analyses, PRDs, design documents, feature specifications, conversation notes, ADRs, requirements lists, or inline descriptions — and produces a plain-language `build-phase-outline.md` indexed by stable phase IDs. Each phase explains what gets built, why it lands at that position, the outcome a real person can be shown end-to-end, cross-references back to the source artifact for traceability, and preconditions. Foundational or prerequisite phases appear
stakeholder-update
Use when drafting, revising, or reviewing stakeholder updates, executive updates, status notes, leadership briefs, decision memos, meeting briefs, presentation notes, update emails, Slack updates, and compressed summaries for readers who need status, risk, decisions, tradeoffs, provenance, or asks. Pair with content-styleguide for deeper prose quality and visual-styleguide for rendered surfaces.
stakeholder-alignment
Align stakeholders in writing using RFCs, design docs, proposals, pre-reads, and decision docs with explicit role assignments (DACI, RAPID). Use when the user asks to write an RFC, design doc, proposal, pre-read, or decision doc, wants to align async stakeholders on a decision, needs to assign deciders vs consulted vs informed, wants to structure a cross-team proposal, or is preparing a pre-read for a decision meeting. NOT for structuring a generic memo (use structured-writing). NOT for stakeholder power maps (use persona-mapping). NOT for storytelling pitches or investor decks (use storytelling-for-stakeholders).