jumpstart-mode 1.1.13 → 1.1.14

package/.jumpstart/skills/grill-me/SKILL.md

@@ -0,0 +1,212 @@
+---
+name: grill-me
+description: 'Rigorously question a plan, design, architecture, proposal, MVP, POC, feature, implementation approach, or technical decision until the assumptions, dependencies, tradeoffs, risks, and next decisions are explicit. Use when the user says grill me, stress test this, poke holes in this, challenge this plan, or asks what they are missing.'
+argument-hint: 'Paste the plan, document, architecture, scope, or repo path you want pressure-tested.'
+---
+
+# Grill Me
+
+## Positioning
+
+Use this skill when the user does not need encouragement or generic feedback. Use it when they need disciplined interrogation that exposes weak assumptions before implementation, estimation, architecture approval, or proposal finalization.
+
+This skill is designed for AI Innovation Pod and Jump Start work, but it also works for broader product, architecture, and delivery planning. Default to a senior architect and delivery-lead posture: direct, skeptical, specific, and constructive.
+
+## What This Skill Does
+
+This skill turns a rough idea, document, plan, or codebase into a decision-by-decision interrogation flow that:
+
+1. identifies the highest-risk unresolved branch
+2. asks exactly one primary question at a time
+3. explains why that question matters
+4. provides a recommended answer or safest default
+5. makes the tradeoff explicit
+6. tracks what the answer unlocks, constrains, or leaves unresolved
+7. ends with a reusable decision summary
+
+The goal is to prevent shallow agreement, hidden dependencies, and accidental scope or architecture commitments.
+
+## When To Use This
+
+- The user says "grill me", "stress test this", "poke holes in this", "challenge this", or "what am I missing?"
+- A plan sounds plausible but the assumptions are still mostly implicit.
+- A proposal, PRD, architecture note, MVP scope, or estimate needs stronger pressure testing.
+- A repo exists and the agent should inspect the codebase before asking human questions.
+- A Jump Start output is about to become Pod scope, estimate language, or an implementation commitment.
+
+## When Not To Use This
+
+- Do not use it when the main need is artifact generation rather than interrogation. Route to the relevant drafting or design skill.
+- Do not use it when the user wants a full written review with findings first and no back-and-forth. In that case, perform the review directly.
+- Do not use it as a substitute for broad discovery analysis of large note sets. Route to `opportunity-intake`, `business-logic-extractor`, or `meeting-recap` first when needed.
+
+## Required Operating Rules
+
+### Rule 1: Ask One Primary Question At A Time
+
+Do not ask a bundle of unrelated questions unless the user explicitly asks for rapid-fire mode.
+
+### Rule 2: Always Explain The Decision
+
+Every question must include:
+
+1. the question
+2. why it matters
+3. the recommended answer or safest default
+4. the tradeoff behind that recommendation
+5. what downstream areas the decision affects
+
+Use the [question pattern](./references/question-pattern.md).
+
+### Rule 3: Inspect The Workspace Before Asking What The Repo Can Answer
+
+If the user points to a codebase, repo, file, package manifest, infrastructure definition, or existing document, inspect those sources before asking the user.
+
+Examples:
+
+- Do not ask what framework is used if `package.json`, project files, or imports answer it.
+- Do not ask whether tests exist if test folders or config files answer it.
+- Do not ask what cloud stack is targeted if infra files already answer it.
+- Do not ask how auth works if middleware, config, routes, or identity docs answer it.
+
+When the workspace answers the question, state the finding and reference the file path.
+
+### Rule 4: Tighten Vague Answers Immediately
+
+If the user answers vaguely, do not move on as if the decision is resolved. Convert the answer into one of:
+
+- decided
+- assumed
+- deferred
+- blocked
+- needs codebase inspection
+- needs stakeholder answer
+- needs external documentation lookup
+- needs spike
+
+### Rule 5: Start With The Highest-Leverage Branch
+
+Do not begin with implementation details if the business goal, workflow bottleneck, MVP boundary, access model, or integration pattern is still unclear.
+
+Use the [decision tree](./references/decision-tree.md) to choose the next branch.
+
+## Interaction Modes
+
+### Interactive Mode
+
+Default mode. Ask one question, wait for the answer, update the working understanding, then move to the next branch.
+
+### Rapid-Fire Mode
+
+Use only if the user explicitly asks for rapid-fire questioning. Keep questions grouped within one decision area rather than scattering across the whole tree.
+
+### Document Review Mode
+
+Use when the user provides a proposal, SOW, PRD, ADR, architecture note, MVP scope, transcript, or workshop output.
+
+Behavior:
+
+1. read the document
+2. extract claims, assumptions, unresolved decisions, and silent dependencies
+3. start with the highest-risk unresolved branch
+4. cite the document when challenging specific claims
+
+### Codebase-Aware Mode
+
+Use when the user points to a repo or working directory.
+
+Behavior:
+
+1. inspect the codebase before asking code-discoverable questions
+2. answer repo-discoverable questions directly
+3. ask only the questions that require human judgment, business context, policy context, or missing external information
+
+## Workflow
+
+1. Identify what is being pressure-tested: plan, scope, proposal, architecture, repo, or implementation path.
+2. Decide the working mode: interactive, rapid-fire, document review, or codebase-aware.
+3. Extract whatever the conversation or workspace already answers.
+4. Choose the highest-risk unresolved decision branch.
+5. Ask one primary question using the required format.
+6. After the user answers, restate the decision in sharper terms.
+7. Update the working log as decided, assumed, deferred, blocked, or needs follow-up.
+8. Move to the next branch only after the current dependency is resolved enough.
+9. Stop when major branches are resolved, the user asks to stop, or a blocker makes further design work low-value.
+10. End with the [summary template](./templates/grill-summary-template.md).
+
+## Default Decision Categories
+
+Consider each category, but only interrogate the ones that materially affect the plan.
+
+1. business goal and success criteria
+2. user and workflow
+3. MVP boundary and scope control
+4. data and source systems
+5. identity, access, and permissions
+6. integration and enterprise architecture
+7. AI, RAG, and agent behavior
+8. RAG document identity and permission preservation
+9. technical architecture and scaling
+10. security, compliance, and legal
+11. operations and support ownership
+12. delivery, estimation, and commercial risk
+
+Use the [decision tree](./references/decision-tree.md) for the fuller branch prompts and branch order.
+
+## Recommended Answer Requirement
+
+Every question must provide a recommended answer.
+
+If context is incomplete, provide the safest default instead of pretending certainty.
+
+Examples:
+
+- Recommend delegated user access with source ACL preservation for retrieval whenever feasible.
+- Recommend an explicit validation spike instead of assuming API access, data quality, or permissions are solved.
+- Recommend narrowing the MVP to the bottleneck step that changes the primary success metric.
+
+## Pod And Jump Start Guardrails
+
+- Separate discovery outputs from implementation commitments.
+- Protect the delivery team by naming dependencies, client responsibilities, and out-of-scope items.
+- Treat governance, observability, evaluation, and human review as first-class design concerns.
+- Do not let "MVP" float between demo-only and production-ready. Force that decision explicitly.
+
+Use these repo references when the user is mixing delivery motions:
+
+- [Jump Start vs AI Pod](../../../05-reference/jumpstart-vs-ai-pod.md)
+- [Understanding the AI Innovation Pod](../../../05-reference/understanding-the-ai-innovation-pod.md)
+- [The JumpStart Workshops](../../../05-reference/the-jumpstart-workshops.md)
+
+## Output Requirements
+
+When the session stops, produce a summary with these sections:
+
+1. decisions made
+2. assumptions accepted
+3. open questions
+4. blockers
+5. recommended spikes
+6. risks
+7. suggested next actions
+8. proposal or SOW language to add
+
+If the user wants a reusable artifact, mirror the [summary template](./templates/grill-summary-template.md).
+
+## Common Failure Modes
+
+- Asking a generic list instead of following the decision tree.
+- Asking the user questions the repo already answers.
+- Moving to implementation details before clarifying success criteria or workflow bottlenecks.
+- Accepting vague answers like "we can probably integrate that" without forcing how.
+- Challenging the plan without providing a recommendation.
+- Ending without a reusable decision summary.
+
+Use the [quality bar](./references/quality-bar.md) to self-check before concluding.
+
+## Example Prompts
+
+- `/grill-me Stress test this AI Innovation Pod MVP scope before I estimate it.`
+- `/grill-me Poke holes in this proposal section and force the hidden dependencies into the open.`
+- `/grill-me Challenge this architecture. The repo is in the workspace, so inspect it before asking me obvious questions.`
+- `/grill-me I have a PRD draft for a document assistant. Interrogate it one decision at a time.`

package/.jumpstart/skills/grill-me/evals/manual-eval-checklist.md

@@ -0,0 +1,50 @@
+# Manual Eval Checklist
+
+Use these prompts to verify that the skill behaves like a decision-tree interrogation workflow instead of a generic checklist.
+
+## Prompt 1: Proposal Pressure Test
+
+`/grill-me Challenge this proposal for a claims assistant. I want one question at a time and I need you to recommend an answer, not just ask questions.`
+
+Pass if:
+
+- the first question targets a high-leverage branch such as success criteria, workflow bottleneck, access, or integration risk
+- the response follows the required question pattern
+- the agent gives a recommendation instead of only interrogating
+
+## Prompt 2: Codebase-Aware Interrogation
+
+`/grill-me Stress test this implementation plan. The repo is in the workspace, so inspect it before asking what framework or auth stack we use.`
+
+Pass if:
+
+- the agent inspects the repo before asking obvious technical questions
+- repo-discoverable findings are stated directly with file references
+- only human-judgment questions remain
+
+## Prompt 3: MVP Boundary Discipline
+
+`/grill-me Poke holes in this MVP scope for a RAG assistant. Force me to choose what is demo-only versus production-ready.`
+
+Pass if:
+
+- the skill forces a decision on MVP boundary rather than accepting fuzzy language
+- the questioning makes delivery consequences visible
+- governance, evaluation, and permissions are not ignored
+
+## Prompt 4: Commercial Readiness
+
+`/grill-me Challenge this plan before I turn it into SOW language.`
+
+Pass if:
+
+- proposal assumptions, dependencies, client responsibilities, and spikes are surfaced
+- the final summary includes proposal or SOW language to add
+- the session does not overstate implementation certainty
+
+## Failure Indicators
+
+- the skill emits a long unordered checklist instead of one primary question at a time
+- the skill asks what the repo already answers
+- the skill never provides a recommended answer
+- the skill ends without a summary artifact

package/.jumpstart/skills/grill-me/examples/document-review-example.md

@@ -0,0 +1,45 @@
+# Example Session
+
+## User Prompt
+
+`/grill-me Stress test this proposal section for a document intelligence MVP. I want you to challenge the hidden assumptions before we estimate.`
+
+## Good Opening
+
+I am going to interrogate this one decision at a time, starting with the branch that most affects scope and estimate confidence.
+
+## Question 1: Success Criteria
+
+What measurable outcome would make this MVP successful enough that the sponsor would approve moving from Jump Start output to Pod delivery?
+
+**Why I’m asking:**
+Without a measurable success condition, the proposal can drift into a feature list and the estimate will absorb hidden scope.
+
+**My recommended answer:**
+Define one primary business metric and one supporting operational metric. For example: reduce document triage time by 50 percent for the target document type, and reduce manual rework by 30 percent for the selected team.
+
+**Tradeoff:**
+This narrows the MVP and may force features out of scope, but it gives the estimate and acceptance criteria a real boundary.
+
+**This decision affects:**
+MVP scope, workflow prioritization, evaluation approach, acceptance criteria, and proposal language.
+
+## Strong Follow-Up After User Answer
+
+Captured. We are optimizing first for triage-time reduction, not full workflow automation. That means the MVP should focus on the step causing elapsed-time delay, not every downstream enhancement.
+
+## Question 2: Workflow Bottleneck
+
+Which exact step is causing the largest delay today: intake, document retrieval, extraction, human validation, approval, or downstream system entry?
+
+**Why I’m asking:**
+The bottleneck determines whether this is mainly an ingestion problem, a retrieval problem, an extraction problem, or an approval workflow problem.
+
+**My recommended answer:**
+Start with the step contributing the most elapsed time, not the step that is merely the most annoying. If the team does not know, require a short process-measurement spike before estimating build effort.
+
+**Tradeoff:**
+This adds a small discovery burden, but it prevents optimizing the wrong part of the workflow.
+
+**This decision affects:**
+Architecture, data requirements, AI pattern, integration needs, and estimate confidence.

package/.jumpstart/skills/grill-me/references/decision-tree.md

@@ -0,0 +1,165 @@
+# Decision Tree
+
+Use this reference to decide which branch to interrogate next. Start with the unresolved branch that most affects scope, architecture, commercial risk, or delivery sequencing.
+
+## Branch Order Heuristic
+
+Start at the earliest unresolved branch in this order unless a later branch is clearly the higher-risk blocker.
+
+1. business goal and measurable success
+2. workflow bottleneck and user behavior change
+3. MVP boundary and what is explicitly excluded
+4. data availability and source ownership
+5. access, identity, and permission model
+6. integration path and environmental constraints
+7. AI pattern, human approval, and evaluation method
+8. architecture, operational ownership, and scale expectations
+9. security, legal, and compliance constraints
+10. estimation, commercial assumptions, and delivery blockers
+
+## Branch Prompts
+
+### 1. Business Goal And Success Criteria
+
+Use when the idea sounds feature-heavy but outcome-light.
+
+Test for:
+
+- the problem being solved
+- the business owner
+- the primary success metric
+- the smallest useful version
+- what happens if nothing is built
+- what is explicitly out of scope
+
+### 2. User And Workflow
+
+Use when the proposed solution does not clearly connect to a real workflow.
+
+Test for:
+
+- who the user is
+- what triggers the workflow
+- what decision or action they are trying to complete
+- where the delay or friction occurs today
+- what happens before and after the proposed solution
+- where human review must remain
+
+### 3. MVP Boundary
+
+Use when the user says MVP, pilot, or POC but the delivery standard is unclear.
+
+Test for:
+
+- what is truly in scope
+- what is deferred
+- what is excluded
+- what is demo-only versus production-ready
+- what could cause hidden scope expansion
+
+### 4. Data And Source Systems
+
+Use when the plan depends on data quality, retrieval, historical context, or source-system truth.
+
+Test for:
+
+- what data is required
+- where it lives
+- who owns it
+- data shape and cleanliness
+- whether IDs are stable
+- whether ground truth exists
+- whether historical data is required
+
+### 5. Identity, Access, And Permissions
+
+Use when the system touches enterprise data, user-specific retrieval, approvals, or actions.
+
+Test for:
+
+- identity provider
+- MFA expectations
+- delegated versus app-level permissions
+- role and group availability
+- row-level, document-level, or tenant-level boundaries
+- service-account assumptions
+
+### 6. Integration And Enterprise Architecture
+
+Use when the plan says "integrate with X" without naming how.
+
+Test for:
+
+- API, file, database, event, or RPA integration path
+- gateway constraints such as Apigee
+- on-prem connectivity
+- firewall, VPN, allowlist, or Private Link needs
+- read versus write path
+- sync versus async behavior
+- environment and sandbox availability
+
+### 7. AI, RAG, And Agent Behavior
+
+Use when AI is part of the plan and its boundaries are still loose.
+
+Test for:
+
+- whether the model generates, summarizes, classifies, extracts, decides, or acts
+- what must be grounded and cited
+- what requires human approval
+- what the no-answer behavior is
+- how hallucinations are handled
+- what eval set or telemetry exists
+- what prompt-injection or misuse risks exist
+
+### 8. RAG Identity And Permission Preservation
+
+Use when the design depends on document retrieval or citations.
+
+Test for:
+
+- durable source object IDs
+- chunk-to-source linkage
+- ACL preservation
+- permission checks at ingestion versus retrieval
+- delete and permission-change handling
+- whether citations are permission-aware
+- whether users can open the original source
+
+### 9. Technical Architecture And Operations
+
+Use when the proposal is hand-wavy about delivery shape or runtime responsibilities.
+
+Test for:
+
+- frontend, backend, and database choices
+- worker or queue needs
+- hosting target
+- observability requirements
+- failure modes
+- scale expectations
+- post-MVP ownership
+- support and rollback model
+
+### 10. Delivery And Commercial Risk
+
+Use when the outcome will influence estimate, proposal, or SOW language.
+
+Test for:
+
+- unresolved dependencies that block estimating
+- assumptions that must be written into proposal language
+- discovery spikes required before commitment
+- testable acceptance criteria
+- what should be priced separately
+- what would invalidate fixed-scope confidence
+
+## Branch Escalation Rule
+
+If the current answer reveals a more foundational unresolved branch, step back.
+
+Example:
+
+- If the user starts debating models before defining the workflow bottleneck, go back to workflow.
+- If the user wants estimate confidence without clarifying access and integration constraints, go back to those constraints first.
+- If the user wants production claims without deciding demo-only versus production-ready, force that decision immediately.

package/.jumpstart/skills/grill-me/references/quality-bar.md

@@ -0,0 +1,27 @@
+# Quality Bar
+
+Before concluding a grilling session, check the following:
+
+## Required
+
+- The questioning started from the highest-leverage unresolved branch.
+- The agent asked one primary question at a time unless the user explicitly requested rapid-fire mode.
+- Each question included why it matters, a recommendation, a tradeoff, and downstream impact.
+- Repo-discoverable questions were answered from the workspace instead of asked of the user.
+- Vague answers were tightened into explicit decisions, assumptions, deferrals, blockers, or spikes.
+- The session ended with a reusable summary.
+
+## Pod And Jump Start Discipline
+
+- Discovery outputs were not presented as implementation commitments.
+- Dependencies, client responsibilities, and out-of-scope items were made visible.
+- Governance, observability, evaluation, and human review were not treated as optional afterthoughts.
+- MVP was forced into a clear delivery standard: demo-only, pilot, or production-ready.
+
+## Failure Smells
+
+- The conversation turned into a generic brainstorming session.
+- The agent asked broad categories like "What about integrations?" instead of a real decision question.
+- The agent challenged the plan but never gave a recommended answer.
+- The agent kept pressing technical details while business success remained fuzzy.
+- The final summary reads like vague notes instead of a decision artifact.

package/.jumpstart/skills/grill-me/references/question-pattern.md

@@ -0,0 +1,39 @@
+# Question Pattern
+
+Use this structure for every primary question unless the user explicitly asks for a different format.
+
+```md
+## Question [N]: [Decision Area]
+
+[One clear question]
+
+**Why I’m asking:**
+[Explain the consequence of the decision.]
+
+**My recommended answer:**
+[Provide the recommended answer or the safest default.]
+
+**Tradeoff:**
+[Explain what the recommendation optimizes for and what it gives up.]
+
+**This decision affects:**
+[List the downstream areas changed by the answer.]
+```
+
+## Response Handling Pattern
+
+After the user answers:
+
+1. restate the answer in sharper terms
+2. mark it as decided, assumed, deferred, blocked, or needs follow-up
+3. explain what the answer now rules in or rules out
+4. move to the next dependency-aware branch
+
+## Tightening Prompts
+
+Use prompts like these when the answer is weak:
+
+- "That is still a preference, not a decision. Which option are we actually committing to for the MVP?"
+- "You are assuming access is straightforward. I would not carry that as solved without an explicit validation step."
+- "This sounds like a future-state aspiration. What is the smallest version we can commit to now?"
+- "If this dependency fails, what is the fallback path?"

package/.jumpstart/skills/grill-me/templates/grill-summary-template.md

@@ -0,0 +1,39 @@
+# Grill Me Summary
+
+## What Was Reviewed
+
+- Artifact or plan:
+- Mode used:
+- Current delivery stage:
+
+## Decisions Made
+
+-
+
+## Assumptions Accepted
+
+-
+
+## Open Questions
+
+-
+
+## Blockers
+
+-
+
+## Recommended Spikes
+
+-
+
+## Risks
+
+-
+
+## Suggested Next Actions
+
+-
+
+## Proposal / SOW Language To Add
+
+-

package/.jumpstart/skills/grill-summary-to-proposal/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: grill-summary-to-proposal
+description: Turn a Grill Me summary into proposal assumptions, validation spikes, client responsibilities, out-of-scope boundaries, and SOW redlines. Use when a pressure-test session already surfaced risks and unresolved decisions and the team now needs proposal-safe language instead of another interrogation round.
+argument-hint: Paste the Grill Me summary, proposal draft, or decision notes that need to become proposal-safe language.
+---
+
+# Grill Summary To Proposal
+
+## Positioning
+
+Use this skill after a `grill-me` session when the team needs to convert the resulting decisions, risks, blockers, and open questions into proposal-ready or SOW-ready guardrails.
+
+This skill does not re-run the interrogation. It operationalizes the outcome so proposal and delivery teams do not lose the pressure-test insights when the work moves into scope, commercial language, or contract review.
+
+## When To Use This
+
+- The user already has a Grill Me summary and wants proposal or SOW language.
+- A scope or estimate is about to move into proposal packaging and the hidden assumptions need to be made explicit.
+- The team needs validation spikes, client responsibilities, and out-of-scope boundaries written clearly.
+- A delivery lead wants redline-ready language that protects the team from unresolved dependencies.
+
+## When Not To Use This
+
+- Do not use it before the interrogation work exists. Run `grill-me` first if the risks and decisions have not been pressure-tested.
+- Do not use it when the user needs a full proposal narrative from scratch. Route to `proposal-narrative` or `rfp-response-writer` instead.
+- Do not use it when the draft already contains redlines and the user mainly needs surgical edits. Route to `proposal-redline-fixer` or `sow-proposal-reviewer`.
+
+## Required Inputs
+
+- A Grill Me summary, decision log, or equivalent notes
+- Optional existing proposal, SOW, PRD, or estimate language
+- Optional target motion: Jump Start, Ignition, Turbo, Overdrive, or another delivery shape
+
+If the summary is incomplete, normalize it first using the [normalization pattern](./references/normalization-pattern.md).
+
+## Core Objective
+
+Transform pressure-test findings into a proposal-safe package that:
+
+1. separates confirmed facts from assumptions
+2. identifies what must be written as a dependency or validation spike
+3. converts risk into proposal or SOW guardrails
+4. clarifies client and vendor responsibilities
+5. makes out-of-scope limits explicit
+6. prevents the draft from implying implementation certainty that does not yet exist
+
+## Workflow
+
+1. Read the Grill Me summary and extract decisions, assumptions, open questions, blockers, and risks.
+2. Separate what is confirmed from what remains hypothetical.
+3. Convert unresolved or dependency-heavy items into explicit proposal assumptions or validation spikes.
+4. Convert operational or access dependencies into client responsibilities, environment prerequisites, or out-of-scope statements.
+5. Convert risky or ambiguous wording into SOW redlines using the [redline patterns](./references/redline-patterns.md).
+6. Produce the output using the [proposal hardening template](./templates/proposal-hardening-template.md).
+
+## Output Structure
+
+For substantial requests, produce these sections unless the user asks for a narrower deliverable:
+
+1. proposal assumptions to add
+2. validation spikes or prerequisite discovery
+3. client responsibilities and dependencies
+4. vendor responsibilities and delivery boundary
+5. out-of-scope language
+6. SOW redlines or wording changes
+7. commercial watchouts
+8. recommended next action
+
+## Guardrails
+
+- Do not pretend blockers are solved just because the proposal needs to move.
+- Do not turn assumptions into committed scope.
+- Do not hide access, data, identity, or environment dependencies inside vague language.
+- Do not use generic consulting filler when a direct redline or scoped assumption is needed.
+
+## Reference Files
+
+- Use the [normalization pattern](./references/normalization-pattern.md) when the summary is messy or partial.
+- Use the [redline patterns](./references/redline-patterns.md) to turn risks into safer proposal wording.
+- Use the [proposal hardening template](./templates/proposal-hardening-template.md) for reusable output.
+- Use the [worked example](./examples/from-grill-summary-example.md) when the user needs to see the expected transformation.
+
+## Related Repo References
+
+- [Jump Start vs AI Pod](../../../05-reference/jumpstart-vs-ai-pod.md)
+- [Understanding the AI Innovation Pod](../../../05-reference/understanding-the-ai-innovation-pod.md)
+- [AI Innovation Pod Tier Matrix](../../../05-reference/ai-innovation-pod-tier-matrix.md)
+
+## Example Prompts
+
+- `/grill-summary-to-proposal Turn this Grill Me summary into proposal assumptions and spikes.`
+- `/grill-summary-to-proposal Convert these decision notes into SOW guardrails and redlines.`
+- `/grill-summary-to-proposal We already pressure-tested the scope. Now write the commercial watchouts clearly.`