Kit Preamble — meeting-capture

---

name: meeting-capture description: Converts sales-written meeting notes (discovery type) into a PRD draft for PoC building, and updates account_brief.md with newly learned facts. The bridge between sales discovery and engineering PoC. Run after a discovery meeting, before /kickoff. argument-hint: <meeting_notes_path> [prd_output_path, default docs/prd_draft.md] disable-model-invocation: false allowed-tools: Read, Glob, Grep, Write, Edit, Task

Kit Preamble — meeting-capture

Kit Update Check

Run silently at the start:

python3 scripts/kit_update_check.py 2>/dev/null

If exit code is 1 (update available), show the output to the user once. Do not block the workflow.

Project Context Detection

Run these checks silently at the start. Use results to adapt behavior:

• [ -f issues.md ] — if true, this project uses the sprint system. Respect issue numbering and STATUS.md.
• [ -f docs/sprint_state.md ] — if true and Status shows running, a sprint is active. Be aware of parallel work in worktrees.
• [ -f docs/prd_digest.md ] — if true, read it for quick project context before starting.

Behavioral Rules

• Verify gh auth status before any GitHub operation.
• Never commit secrets, API keys, or credentials. Use environment variables.
• Prefer parallel Read/Glob/Grep tool calls when reading multiple independent files.
• When uncertain about intent, ask the user rather than guessing.
• Respect existing project conventions (package manager, test framework, code style).

Contributor Mode

At the start of this skill, check if contributor mode is enabled:

python3 scripts/kit_config.py get contributor_mode

If the result is true:

1. At the end of each major workflow step, self-rate your experience with the kit 0–10.
2. If rating < 10 and there is an actionable improvement, file a field report:

   python3 scripts/contributor_report.py --skill <name> --step "<step>" --rating <N> --notes "<friction or suggestion>"
   

3. Maximum 3 reports per session. Skip if a report for the same step already exists.
4. Do NOT stop the workflow to file reports — do it inline.
5. Only report kit/skill issues (unclear instructions, missing checkpoints, bad ergonomics). Do NOT report user-app bugs or network errors. Steps:

1. Parse arguments:
   • $1 (required): meeting notes file path. Must exist.
   • $2 (optional): PRD output path, default docs/prd_draft.md.
2. Validate the meeting notes file exists. If not, stop and ask the user for the correct path.
3. Read the meeting notes and confirm meeting_type field.
   • If discovery or closing: proceed.
   • If demo: stop. Tell the user to run /proposal <notes_path> instead.
   • If missing or unclear: ask the user.
4. Check if docs/account_brief.md exists. Recommended but not required. If missing, warn the user that PRD context will be weaker.
5. Check if the PRD output file already exists. 5.5) Resolve shared file paths via walk-up (supports multi-account repo structure):

   LESSONS_PATH="$(bash scripts/find_shared.sh sales_lessons.md 2>/dev/null || true)"
   

   • If non-empty, pass the absolute path to the agent.
   • If empty, proceed without lessons context.

If PRD does NOT exist (New PRD):

6a) Invoke the meeting-synthesizer agent via the Task tool, passing: - meeting notes path - PRD output path - account_brief path (if exists) - Resolved LESSONS_PATH from step 5.5 (or None if unresolved) 7a) The agent will: - Read meeting notes, account brief, docs/example_prd.md, templates/prd_digest.md (if exists) - Optionally read the resolved sales_lessons.md path (passed in) for cross-account patterns - Extract pains, requirements, constraints, success criteria - Scope down to demo-grade PoC: pick ONE primary flow, mock externals, explicit Out-of-Scope - Generate PRD draft with sections in order: Background, PoC Goal, Target User, User Stories, PoC Deliverables (one-shot demo artifacts), Productionalizable Features (real product features), Out of Scope, Success Criteria, Brand Customization, Demo Narrative, Open Questions - Save PRD to output path - Atomically update account_brief.md via Read+Write (not multiple Edits): Active Context section, meeting history, decision structure, unresolved questions, champion status 8a) Present to the user: - Top 3 things learned - The 1 PoC primary flow proposed - Ambiguities the salesperson must resolve before PoC build

If PRD DOES exist (Accumulate):

6b) Read existing PRD and present a brief summary. 7b) Ask the user: append to existing PRD (new info from new meeting) or rewrite? 8b) Invoke meeting-synthesizer in update mode. 9b) Highlight what changed in the PRD and what was added to account_brief.

Common (both modes):

9. After PRD is finalized and ambiguities resolved, inform the user the next step is:

   /kickoff <prd_output_path>     # add --mode=demo if implemented
   /uiux
   /sprint                         # add --mode=demo if implemented
   

   to build the PoC. After PoC build + demo meeting:

   # fill in docs/poc_results.md using templates/poc_results.md
   /proposal <demo_meeting_notes>
   

   Note: --mode=demo flag on /kickoff and /sprint skips production-grade gates (full architecture doc, data model, test plans). If those flags are not yet implemented in your project, run /kickoff and /sprint normally — the demo-scope discipline lives in the PRD itself (the "Out of Scope" + "PoC Deliverables" sections).

   poc_results.md is REQUIRED before /proposal — without it, proposal claims become unverifiable. Sales + engineer fill it in together after the demo meeting.

Error Handling

• If meeting notes file does not exist: stop and ask for correct path.
• If meeting type is demo: redirect to /proposal.
• If account_brief.md is missing: warn but proceed.
• If the PRD output path is not writable: report and ask for alternative.

Quality Criteria

NEVER:

• Invent customer requirements not present in the notes
• Build a production-grade PRD — this is demo scope
• Skip the "Out of Scope" section — it is the most important section
• Forget to update account_brief.md — knowledge must accumulate
• Treat ambiguous customer language as confirmed requirements

INSTEAD:

• Quote the customer directly when stating a pain or requirement
• Default "out of scope" for anything not directly tied to the primary flow
• When in doubt, list under "Open Questions" rather than inventing the answer
• Use customer's industry vocabulary, not internal product jargon
• Explicitly call out brand customization needs

Guidelines

• This skill is the most critical integration point in the sales pack. Quality of PRD draft determines PoC quality.
• After the agent finishes, always ask the salesperson to confirm ambiguities before proceeding to /kickoff.
• After saving, the recommended pipeline:
  1. Resolve PRD ambiguities (manual + salesperson)
  2. /kickoff --mode=demo docs/prd_draft.md (or /kickoff without flag if not implemented)
  3. /uiux for design system + prototype
  4. /sprint --mode=demo (or /sprint) for implementation
  5. Demo with customer
  6. /proposal <demo_meeting_notes> after demo