creating-stakeholder-packet
Guides the creation of a verified Stakeholder Input Packet to define project scope and requirements.
Install
mkdir -p .claude/skills/creating-stakeholder-packet && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/16902" && unzip -o skill.zip -d .claude/skills/creating-stakeholder-packet && rm skill.zipInstalls to .claude/skills/creating-stakeholder-packet
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Use when a delivery run needs a Stakeholder Input Packet and none exists or the existing one has gaps, OPEN items, hedges, or contradictions — e.g., the project idea lives in a conversation, loose notes, or a short brief. Required before the requirements-analyst agent (and therefore the whole pipeline) can run.Key capabilities
- →Interview stakeholders to define project requirements
- →Map stakeholder input to a standardized 17-section packet
- →Resolve contradictions and hedges in project ideas
- →Draft business rules and acceptance examples from stakeholder input
- →Confirm packet sections verbatim with stakeholders
How it works
This skill conducts an interview loop to extract and structure business truths from stakeholders into a 17-section input packet. It maps input, resolves ambiguities, drafts sections, and confirms them verbatim with the stakeholder, ensuring every statement is stakeholder-confirmed.
Inputs & outputs
When to use creating-stakeholder-packet
- →Define new project requirements
- →Resolve contradictions in project briefs
- →Formalize informal project ideas
- →Prepare data for agent pipelines
About this skill
Creating the Stakeholder Input Packet
Overview
The packet (template: templates/stakeholder-input-packet.md, sections §1–§17) is the sole source of business truth for the entire agent pipeline. Core principle: nothing enters the packet that the stakeholder did not say or explicitly confirm. This skill extracts the packet through an interview. It never authors business truth — a drafted rule the stakeholder never confirmed is corrupted input that every downstream agent will faithfully build on.
When to Use
- New project: the idea exists only in someone's head, chat messages, or a short brief.
- An existing packet draft has
OPENitems, hedges ("maybe", "I think"), or contradictions to resolve.
Do NOT use for:
- A complete, confirmed packet → invoke the
delivery-orchestratoragent directly. - A mid-run scope change → write a packet amendment per the Agent Handoff Protocol §3.3. Never edit the frozen copy under
runs/<run-id>/00-packet/, never restart the interview.
The Interview Loop
digraph interview_loop {
"Intake: map input to §1–§17" [shape=box];
"Any section EMPTY/PARTIAL, hedge, or contradiction?" [shape=diamond];
"Interview round (≤4 questions)" [shape=box];
"Read back §5, §8, §13, §15 for confirmation" [shape=box];
"Completeness gate passes?" [shape=diamond];
"Save packet, hand off to pipeline" [shape=box];
"Intake: map input to §1–§17" -> "Any section EMPTY/PARTIAL, hedge, or contradiction?";
"Any section EMPTY/PARTIAL, hedge, or contradiction?" -> "Interview round (≤4 questions)" [label="yes"];
"Interview round (≤4 questions)" -> "Any section EMPTY/PARTIAL, hedge, or contradiction?" [label="update map"];
"Any section EMPTY/PARTIAL, hedge, or contradiction?" -> "Read back §5, §8, §13, §15 for confirmation" [label="no"];
"Read back §5, §8, §13, §15 for confirmation" -> "Completeness gate passes?";
"Completeness gate passes?" -> "Save packet, hand off to pipeline" [label="yes"];
"Completeness gate passes?" -> "Interview round (≤4 questions)" [label="no — gaps remain"];
}
Phase 1 — Intake & Mapping
- Read the template
templates/stakeholder-input-packet.mdin full first — its prompts AND its worked example set the expected level of detail. - Collect whatever input exists. Quote-map every stakeholder statement to a section §1–§17.
- Mark each section: FILLED = its template prompt could be answered without further asking; PARTIAL = statements map to it but fall short of the template's detail; EMPTY = nothing maps. List every hedge and contradiction separately — each must be resolved by a question, never hardened into a fact.
- Persist the map, the hedge/contradiction lists, and the pending question queue to
packet-interview-state.mdnext to the intended packet destination. This file is working state, never the packet; resume an interrupted interview from it. An unconfirmed packet is never saved as the packet — if the stakeholder becomes unavailable, the work stays in this file.
Phase 2 — Interview Rounds
- ≤4 questions per round. Plain language only — the stakeholder is non-technical; no schema/auth/API vocabulary.
- Use
AskUserQuestionwhen available (concrete options + free-text always possible); otherwise numbered questions in chat. - Priority order: §1–§5 (identity, roles, journeys, features, rules) → §6–§9 (data, touchpoints, permissions, privacy) → §10–§15 → §16–§17.
- One topic per question. Show the expected detail level by borrowing from the template's worked example.
- "I don't know" is a valid answer → mark
OPENwith enough context for the Requirements Analyst to form a clarification question.OPENis permitted only after the stakeholder was actually asked. - Convert every relative date to an absolute date (today + offset). Collect domain words for §17 as they appear.
- Money, identity, and irreversibility hide the biggest gaps: if anything is charged, paid, refunded, deleted, or restricted, drill until the rule is a single testable sentence (amount, boundary moment, who can override).
Per-section question bank and gap probes: see interview-guide.md in this directory.
Phase 3 — Draft & Read-Back
Draft each section in the stakeholder's own words. Then read back verbatim for explicit confirmation the four normative sections:
| Section | Becomes |
|---|---|
| §5 Business Rules | system invariants + automated safety tests |
| §8 Permissions | the enforced permission matrix |
| §13 Acceptance Examples | the release gate |
| §15 Out of Scope | orphan detection; unlisted = excluded by default |
A "yes, that's right" from the stakeholder is required per section. Unconfirmed drafts of these sections may not ship in the packet.
When you reword a vague answer into a testable sentence (common for §5 rules and §13 examples), the reworded sentence you read back and the stakeholder confirms becomes their wording. §17 glossary definitions are confirmed the same way.
Phase 4 — Completeness Gate
All must hold before saving:
- All 17 sections present; each FILLED or carrying explicit
OPENitems. - §2: every role has who / approximate count / needs. §8 covers every §2 role with can / can-never.
- §3: 3–7 journeys, each with at least one thing-goes-wrong path.
- §4: every feature tagged MUST / SHOULD / LATER. No effort or time estimates anywhere in the packet (an absolute deadline date in §14 is a constraint, not an estimate).
- §5: each rule is one testable plain sentence.
- §13: 5–10 concrete, checkable statements.
- §16: a named human decision-maker with response expectations.
- No unconfirmed hedges, no relative dates, every contradiction resolved or
OPEN. - Spot-check against the template's traceability appendix: each section's consuming agents could act on what is written.
Phase 5 — Save & Hand Off
- Confirm the file destination with the operator running the session. Default:
runs/<yyyy-mm>-<project-slug>/00-packet/stakeholder-input-packet.md(the frozen copy per the Agent Handoff Protocol §1). Content confirmations always come from the stakeholder; file-location and process confirmations come from the operator — these may be different people. - Delete or archive
packet-interview-state.mdonce the packet is saved. - Recommend the next step: invoke the
delivery-orchestratoragent for a full run, or therequirements-analystagent directly for a packet dry-run before committing to a run.
Common Mistakes
| Mistake | Reality |
|---|---|
Drafting the whole packet from the brief, flagging gaps as OPEN without asking | That is the Requirements Analyst's failure mode inverted. This skill exists to ASK. OPEN only after the question was put to the stakeholder. |
| Hardening hedges ("maybe WhatsApp" → "WhatsApp notifications: MUST") | A hedge is a question, not a decision. Ask, or carry the hedge as OPEN. |
| Inventing journeys, permissions, or acceptance examples "as a starting point" and moving on | Proposing options inside a question is fine. Recording them as packet content without a "yes" is fabrication. |
| Firehosing 15 questions at once | Stakeholders abandon long questionnaires. ≤4 per round, highest-priority gaps first. |
| Leaving "in three months" in the packet | Downstream agents cannot resolve it. Write the absolute date. |
| Treating "I don't know" as failure | It is signal. Mark OPEN; the analyst batches it for the decision-maker. |
| Skipping the read-back because answers were clear | §5/§8/§13/§15 become tests, gates, and enforcement. Confirmation is the contract. |
Red Flags — Stop and Return to the Loop
- You are writing a §5 rule or §8 permission the stakeholder never stated.
- You are about to save with a section you never asked about.
- A question round contains technical vocabulary.
- "The example packet had X, so this project probably needs X too" — the worked example calibrates detail, it does not supply content.
When not to use it
- →For a complete, confirmed packet
- →For a mid-run scope change
- →When the project idea is already fully documented and confirmed
Limitations
- →nothing enters the packet that the stakeholder did not say or explicitly confirm.
- →An unconfirmed packet is never saved as the packet
- →`OPEN` is permitted only after the stakeholder was actually asked.
How it compares
This process strictly adheres to documenting only confirmed stakeholder statements, preventing assumptions or interpretations from entering the requirements, unlike informal brief-to-document conversion.
Compared to similar skills
creating-stakeholder-packet side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| creating-stakeholder-packet (this skill) | 0 | 2mo | No flags | Advanced |
| pmbok-project-management | 38 | 9mo | No flags | Intermediate |
| project-planner | 32 | 10mo | Review | Intermediate |
| spec-kit-workflow | 11 | 8mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
pmbok-project-management
jgtolentino
Comprehensive PMP/PMBOK project management methodologies and best practices. Use this skill when users need guidance on project management processes, templates, knowledge areas, process groups, tools, techniques, or certification preparation. Covers all 10 PMBOK Knowledge Areas and 5 Process Groups with practical templates, frameworks, and industry-standard approaches. Includes risk management, stakeholder engagement, schedule management, cost control, quality assurance, and resource planning.
project-planner
adrianpuiu
Comprehensive project planning and documentation generator for software projects. Creates structured requirements documents, system design documents, and task breakdown plans with implementation tracking. Use when starting a new project, defining specifications, creating technical designs, or breaking down complex systems into implementable tasks. Supports user story format, acceptance criteria, component design, API specifications, and hierarchical task decomposition with requirement traceability.
spec-kit-workflow
jmanhype
Guides specification-driven development workflow. Automatically invoked when discussing new features, specifications, technical planning, or implementation tasks. Ensures proper workflow phases (specify → clarify → plan → checklist → tasks → analyze → implement).
product-manager-toolkit
davila7
Comprehensive toolkit for product managers including RICE prioritization, customer interview analysis, PRD templates, discovery frameworks, and go-to-market strategies. Use for feature prioritization, user research synthesis, requirement documentation, and product strategy development.
planning-agent
parcadei
Planning agent that creates implementation plans and handoffs from conversation context
pdd
mikeyobrien
Transforms a rough idea into a detailed design document with implementation plan. Follows Prompt-Driven Development — iterative requirements clarification, research, design, and planning.