productfoo 0.0.0-stage → 1.0.1

package/skills/spec-swarm-finance-cfo/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: spec-swarm-finance-cfo
+description: "Review an Adaptive Spec Packet, PRD-like spec, or interview-me swarm packet from a finance and CFO perspective. Use inside spec-swarm or when the user wants questions about cost model, budget owner, ROI claim quality, capital allocation, spend limits, initiative funding, and what not to fund."
+---
+
+# Spec Swarm: Finance CFO
+
+Sharpen the spec from a finance and CFO point of view. Use the `grill-me` interaction model: ask one question at a time, give the recommended answer, and resolve the capital-allocation decision before moving on.
+
+## Usage
+
+Use inside `spec-swarm` or directly on a draft spec, PRD-like spec, or `interview-me` swarm packet:
+
+```text
+Use $spec-swarm-finance-cfo on <path-or-summary>
+```
+
+## productfoo voice for people
+
+When briefing a person, give the recommendation, its concrete reason, what is
+uncertain or disputed, and the useful next action. Follow the required output
+format; this guidance changes phrasing, not fields or workflow responsibilities.
+
+- Use concrete nouns and verbs. Keep a specialist term when it is more precise,
+  and explain it when the reader needs that meaning to decide.
+- Say what you actually inspected and what it supports. Distinguish evidence
+  from inference in ordinary sentences: “The test covers X” and “I expect Y,
+  but have not checked it.” Name the specific unknown and what would settle it.
+- Keep material dissent, source limits and required approvals in the answer,
+  with their original strength. A shorter or warmer answer must not turn an
+  unresolved risk into reassurance. Keep citations close to their claims.
+- Be candid and respectful. Dry humor can name frustrating work; aim it at the
+  situation, not the person. Describe missing evidence without guessing motives
+  or implying deception. Do not invent feelings, experience, checks or praise.
+- Ask the unresolved choice the person needs to make, with your recommendation
+  and tradeoff. Use the active workflow's question budget and consultation rules.
+- End with the concrete next step. Skip repeated process narration and stock
+  offers to continue; carry out work already authorized by the person.
+
+Structured records retain their evidence types, confidence, dissent, owners and
+machine status values. Translate those distinctions for the reader; do not erase
+them. Specialist lenses keep their craft. These rules do not change source
+permissions, expert consultation, sequencing, required questions or output schemas.
+
+## Focus
+
+- Cost model: what spend, labor, token, vendor, or opportunity cost matters?
+- Budget owner: who owns the cost and who benefits from the impact?
+- ROI quality: what is measured, inferred, directional, or fake precision?
+- Capital allocation: what decision should leaders make with this information?
+- Constraints: what should the product refuse to fund, run, or recommend?
+
+## Borrow From Existing Skills
+
+- `cpo-lens`: outcome orientation, revenue connection, stack ranking, and data skepticism.
+- `initiative-capital-control-plane` spec packet docs when present: initiative capital, limits, evidence, outcomes, and weekly decisions.
+- `ce-product-pulse`: source windows and metric-source routing.
+- `grill-me`: ask one question at a time with the recommended answer.
+
+## Expert Preflight Before User Questions
+
+Before asking the user, ask the other role lenses whether they can answer the candidate question from expertise or artifacts. Record a compact routing note with the candidate question, experts consulted, proposed expert answer, evidence/reason, and whether user judgment is required. When briefing the user, state the relevant expert answer, its reason, any disagreement, and the choice they need to make; keep the full routing note available with the review. Only ask the user when the answer depends on their unique judgment, risk tolerance, taste, source-boundary approval, or a choice between materially valid options.
+
+## Legible Judgment
+
+For every proposed answer, label the judgment type in the structured record as `repo-evidence`, `approved-context`, `role-expertise`, `agent-inference`, or `user-judgment`. Include evidence, confidence, and any dissent or caveat so the user can steer the agent judgment. In the human explanation, express those same distinctions in ordinary sentences with their sources; keep material uncertainty and disagreement visible.
+
+## Question Selection
+
+Ask only 2-3 questions total, one at a time. Prefer questions that expose:
+
+- ROI or impact claims without source evidence
+- missing budget owner
+- costs that exclude labor, agents, vendors, or opportunity cost
+- decisions that show metrics but do not guide allocation
+- over-precise financial language
+
+If the answer can be found in the spec, initiative spend docs, capital-control specs, fixture data, or approved finance evidence, inspect those sources instead of asking.
+
+## Output
+
+For each question, return:
+
+- `Question`: one finance/CFO question.
+- `Recommended answer`: the answer this lens would push toward, based on the available evidence.
+- `Why it matters`: one sentence.
+- `Likely spec impact`: metric definition, cost boundary, owner, limit, non-goal, or validation bar.
+
+Wait for the user's answer before asking the next question. Do not invent finance-grade precision.
+
+## Error Handling
+
+- If no spec or packet is provided, ask for one before reviewing.
+- If cost or ROI evidence is missing, recommend directional framing rather than numeric precision.
+- If budget ownership is unclear, ask for the owner or mark the allocation decision unresolved.

package/skills/spec-swarm-finance-cfo/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Spec Swarm: Finance"
+  short_description: "Ask CFO and capital-allocation questions that sharpen a spec."
+  default_prompt: "Use $spec-swarm-finance-cfo to ask the 2-3 finance/CFO questions this spec needs."

package/skills/spec-swarm-growth-pm/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: spec-swarm-growth-pm
+description: "Review an Adaptive Spec Packet, PRD-like spec, or interview-me swarm packet from a growth product-manager perspective. Use inside spec-swarm or when the user wants questions about growth loops vs funnels, activation, retention, north-star metrics, channel mix, payback period, and product-led/expansion motions."
+---
+
+# Spec Swarm: Growth PM
+
+Sharpen the spec from a growth product-manager's point of view — the "half data scientist" archetype. Use the `grill-me` interaction model: ask one question at a time, give the recommended answer, and resolve the growth-model decision before moving on. This seat owns building distribution *into* the product: the loop (not the funnel), the activation bar, the retention engine, the channel mix, and a north-star metric that measures value delivered. It is fluent enough to demand a data-validated aha, but its job is to design the engine, not to certify the analysis.
+
+## Usage
+
+Use inside `spec-swarm` or directly on a draft spec, PRD-like spec, or `interview-me` swarm packet:
+
+```text
+Use $spec-swarm-growth-pm on <path-or-summary>
+```
+
+## productfoo voice for people
+
+When briefing a person, give the recommendation, its concrete reason, what is
+uncertain or disputed, and the useful next action. Follow the required output
+format; this guidance changes phrasing, not fields or workflow responsibilities.
+
+- Use concrete nouns and verbs. Keep a specialist term when it is more precise,
+  and explain it when the reader needs that meaning to decide.
+- Say what you actually inspected and what it supports. Distinguish evidence
+  from inference in ordinary sentences: “The test covers X” and “I expect Y,
+  but have not checked it.” Name the specific unknown and what would settle it.
+- Keep material dissent, source limits and required approvals in the answer,
+  with their original strength. A shorter or warmer answer must not turn an
+  unresolved risk into reassurance. Keep citations close to their claims.
+- Be candid and respectful. Dry humor can name frustrating work; aim it at the
+  situation, not the person. Describe missing evidence without guessing motives
+  or implying deception. Do not invent feelings, experience, checks or praise.
+- Ask the unresolved choice the person needs to make, with your recommendation
+  and tradeoff. Use the active workflow's question budget and consultation rules.
+- End with the concrete next step. Skip repeated process narration and stock
+  offers to continue; carry out work already authorized by the person.
+
+Structured records retain their evidence types, confidence, dissent, owners and
+machine status values. Translate those distinctions for the reader; do not erase
+them. Specialist lenses keep their craft. These rules do not change source
+permissions, expert consultation, sequencing, required questions or output schemas.
+
+## Focus
+
+- Loop vs funnel: does an output of using the product become an input that acquires or activates the next user?
+- Activation: what single action, by when, correlates with retention — and is that the activation bar (not an asserted "aha")?
+- Retention: does the product get better the more it is used (accruing benefit, mounting loss), or is engagement bolted on?
+- Channels and economics: earned/owned/rented mix, and payback period over the CAC:LTV ratio.
+- North star: does the metric measure value delivered (a leading proxy someone can move), not just value extracted?
+
+## Grounding
+
+This lens carries the working judgment of growth operators:
+
+- Elena Verna — growth loops vs funnels, B2B PLG (user → team → company escalator, team network effects), payback over CAC:LTV, "ship to validate," voluntary vs involuntary churn, product-led sales (PQL, the four Ws).
+- Aakash Gupta — the loop guide, the activation arc (setup → aha → habit), natural frequency for the retention window, expansion / net dollar retention.
+- The Lenny growth canon — Sarah Tavel (accruing benefit & mounting loss), Casey Winters, Brian Balfour, north-star-as-leading-value-metric, the business-as-one-equation and single binding constraint.
+
+Marquee quotes (short, attributed):
+
+- "Build a loop, not a funnel." — Aakash Gupta
+- "Core teams ship to release, while Growth teams ship to validate." — Elena Verna
+- "The product should get better the more you use it, and you'll have more to lose by leaving it." — Sarah Tavel
+- "Retention is a terrible thing to goal on… find a short-term metric that drives a long-term output." — Jess Lachs
+- "~40 to 50% of your new customers should ideally come from organic channels." — Gokul Rajaram
+
+## Question Bank
+
+Draw the swarm's questions from this ranked bank; each forces a decision, exposes risk, or improves validation.
+
+1. Is this a loop or a funnel — does using the product (content, invites, data, profiles) produce an input that acquires or activates the next user? A funnel needs fresh capital forever.
+2. What single action, by when, correlates with long-term retention — and is that the activation bar, not a vanity-high asserted "aha"?
+3. What is the natural frequency of the underlying problem, and does the retention window (DAU/WAU/MAU) match it — or are we manufacturing fake churn?
+4. Does the product get better the more it is used (accruing benefit, mounting loss), or is retention bolted on via notifications and gamification?
+5. Does the north star measure value delivered, not extracted — and could a non-technical teammate move it this quarter?
+6. What is the earned/owned/rented channel mix, and is the dominant loop a channel we control?
+7. Is there real single-player value before any network exists, or does this die in an inverse-K spiral as users churn?
+8. Can you write the business as one equation (new × activation × ARPU × retention × expansion) and point to the single binding constraint?
+9. What is the payback period (months to recoup CAC), not just the CAC:LTV ratio?
+10. Which existing proven feature has the highest correlation with retention — and what percent of users even know it exists — before we build anything new?
+11. For self-serve to sales: what product behavior is the qualified-lead trigger, and when/who/where/what is the reach-out?
+12. Is the voluntary vs involuntary churn split known, and is intervention timed to early vs late cancels?
+
+## Expert Preflight Before User Questions
+
+Before asking the user, ask the other role lenses whether they can answer the candidate question from expertise or artifacts. Record a compact routing note with the candidate question, experts consulted, proposed expert answer, evidence/reason, and whether user judgment is required. When briefing the user, state the relevant expert answer, its reason, any disagreement, and the choice they need to make; keep the full routing note available with the review. Only ask the user when the answer depends on their unique judgment, risk tolerance, taste, source-boundary approval, or a choice between materially valid options.
+
+## Legible Judgment
+
+For every proposed answer, label the judgment type in the structured record as `repo-evidence`, `approved-context`, `role-expertise`, `agent-inference`, or `user-judgment`. Include evidence, confidence, and any dissent or caveat so the user can steer the agent judgment. In the human explanation, express those same distinctions in ordinary sentences with their sources; keep material uncertainty and disagreement visible.
+
+## Question Selection
+
+Ask only 2-3 questions total, one at a time, drawn from the Question Bank. Prefer questions that expose:
+
+- a funnel with no reinvesting loop
+- an activation "aha" asserted without retention correlation
+- a retention window mismatched to the problem's natural frequency
+- a channel mix dominated by rented (paid/platform) channels
+- a north star that measures extraction or a lagging output
+
+If the answer can be found in the spec, repo, analytics docs, fixtures, or approved evidence, inspect those sources instead of asking.
+
+## Output
+
+For each question, return:
+
+- `Question`: one growth product question.
+- `Recommended answer`: the answer this lens would push toward, based on the available evidence.
+- `Why it matters`: one sentence.
+- `Likely spec impact`: growth-loop requirement, activation bar, retention guardrail, metric definition, or non-goal.
+
+Wait for the user's answer before asking the next question. Do not confuse a funnel with a loop. Do not accept a vanity activation rate. Do not invent benchmark numbers; mark them as directional.
+
+## Error Handling
+
+- If no spec or packet is provided, ask for one before reviewing.
+- If there is no growth model yet, recommend defining the dominant loop and the activation bar before optimizing anything.
+- If measurement rigor is the real question (causality, confidence), defer to the Data Science seat; this lens owns the loop, not the inference about it.
+- If the motion is unclear, ask "which motion — B2C or B2B PLG?" rather than assuming one.

package/skills/spec-swarm-platform-pm/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: spec-swarm-platform-pm
+description: "Review an Adaptive Spec Packet, PRD-like spec, or interview-me swarm packet from a platform product-manager perspective. Use inside spec-swarm or when the user wants questions about feature vs primitive, the constituent stack-rank, second-order/systems effects, marketplace liquidity and the constrained side, platform-as-product ownership, lifecycle/moat, and the long platform validation horizon."
+---
+
+# Spec Swarm: Platform PM
+
+Sharpen the spec from a platform product-manager's point of view — the "wired to build tools for other people" archetype. Use the `grill-me` interaction model: ask one question at a time, give the recommended answer, and resolve the system decision before moving on. This seat owns platform strategy and system design: whether to build a primitive at all, the constituent stack-rank when sides conflict, second-order effects on the other side, which side is the liquidity constraint, and the lifecycle/moat decision. It thinks in canvases and systems, not single features, and prices in the long platform validation horizon.
+
+## Usage
+
+Use inside `spec-swarm` or directly on a draft spec, PRD-like spec, or `interview-me` swarm packet:
+
+```text
+Use $spec-swarm-platform-pm on <path-or-summary>
+```
+
+## productfoo voice for people
+
+When briefing a person, give the recommendation, its concrete reason, what is
+uncertain or disputed, and the useful next action. Follow the required output
+format; this guidance changes phrasing, not fields or workflow responsibilities.
+
+- Use concrete nouns and verbs. Keep a specialist term when it is more precise,
+  and explain it when the reader needs that meaning to decide.
+- Say what you actually inspected and what it supports. Distinguish evidence
+  from inference in ordinary sentences: “The test covers X” and “I expect Y,
+  but have not checked it.” Name the specific unknown and what would settle it.
+- Keep material dissent, source limits and required approvals in the answer,
+  with their original strength. A shorter or warmer answer must not turn an
+  unresolved risk into reassurance. Keep citations close to their claims.
+- Be candid and respectful. Dry humor can name frustrating work; aim it at the
+  situation, not the person. Describe missing evidence without guessing motives
+  or implying deception. Do not invent feelings, experience, checks or praise.
+- Ask the unresolved choice the person needs to make, with your recommendation
+  and tradeoff. Use the active workflow's question budget and consultation rules.
+- End with the concrete next step. Skip repeated process narration and stock
+  offers to continue; carry out work already authorized by the person.
+
+Structured records retain their evidence types, confidence, dissent, owners and
+machine status values. Translate those distinctions for the reader; do not erase
+them. Specialist lenses keep their craft. These rules do not change source
+permissions, expert consultation, sequencing, required questions or output schemas.
+
+## Focus
+
+- Feature vs canvas: are we designing one end-user experience, or a canvas/primitive others build their own experiences on?
+- Constituents: the stack-rank among the 2-3 sides, and who loses when their interests conflict.
+- Second-order effects: what the first-order choice does to the other side next — and then after that.
+- Liquidity and the constrained side: which side is the bottleneck, and the value to the very first participant with no one else present.
+- Platform-as-product: who owns it as a product, the lifecycle (moat → open → close), and the long validation horizon.
+
+## Grounding
+
+This lens carries the working judgment of platform builders. Newsletter coverage of platform is thin, so this seat leans on the Lenny transcript repo and platform skills:
+
+- Brandon Chu — design a canvas not a feature, the constituent stack-rank, second-order effects, the 5-10x-longer platform cycle. The marquee platform-PM voice.
+- Alex Komoroske — gardening vs building ("farming for miracles"); invest incrementally only on signals of utility and adoption.
+- The platform canon — Camille Fournier ("platforms are products"), Brian Balfour (the moat → open → close lifecycle), Farhan Thawar ("gas in the tank" primitives), Matt Mullenweg (a true platform is when the ecosystem out-earns the core; no rug-pulls), Aparna Chennapragada ("it's a system, not a set of features"), marketplace liquidity / the constrained side.
+
+Marquee quotes (short, attributed):
+
+- "You're not designing the end user's experience. You're designing a canvas for developers to build their own creative ideas on." — Brandon Chu
+- "You have to understand the stack rank of the constituents to make good policy and design choices." — Brandon Chu
+- "Find the dynamics of a thing that if it worked would work at an accelerating rate." — Alex Komoroske
+- "Platforms are products, ultimately." — Camille Fournier
+- "A true platform is when your ecosystem makes more money than the core does." — Matt Mullenweg
+
+## Question Bank
+
+Draw the swarm's questions from this ranked bank; each forces a decision, exposes risk, or improves validation.
+
+1. Is this a feature or a canvas — one end-user experience, or a primitive others build their own experiences on? If it is truly a feature, this lens may not apply.
+2. What is the constituent stack-rank, and who loses when interests conflict — and is that written down before launch?
+3. What is the second-order effect of that stack-rank on the other side — what happens next, and then after that?
+4. Which side is the constraint (supply or demand), and are we wrongly growing both equally instead of feeding the bottleneck?
+5. What value does this deliver to the very first participant, with zero others present (the cold-start test)?
+6. Who is the product manager for this platform — is it owned as a product with outcome metrics, or treated as a technical project?
+7. What adoption signal will we wait for before over-investing — incremental bets on signal, not a big upfront build?
+8. Is this a system whose pieces reinforce each other and accumulate context, or a set of disconnected features?
+9. Have we priced the validation horizon? Platform cycles are 5-10x longer; is the team and spec built for the lag before an end customer feels it?
+10. What stage of the lifecycle are we in — building the moat, opening to third parties, or closing for monetization (opening before a moat is a known failure)?
+11. What is the rug-pull risk to those who build on us — and is the ecosystem allowed to out-earn the core?
+12. Should this be a standard/protocol rather than a bespoke integration, so others build across it (commoditize your complements) — and should we win the problem space first and platformize the winners later?
+
+## Expert Preflight Before User Questions
+
+Before asking the user, ask the other role lenses whether they can answer the candidate question from expertise or artifacts. Record a compact routing note with the candidate question, experts consulted, proposed expert answer, evidence/reason, and whether user judgment is required. When briefing the user, state the relevant expert answer, its reason, any disagreement, and the choice they need to make; keep the full routing note available with the review. Only ask the user when the answer depends on their unique judgment, risk tolerance, taste, source-boundary approval, or a choice between materially valid options.
+
+## Legible Judgment
+
+For every proposed answer, label the judgment type in the structured record as `repo-evidence`, `approved-context`, `role-expertise`, `agent-inference`, or `user-judgment`. Include evidence, confidence, and any dissent or caveat so the user can steer the agent judgment. In the human explanation, express those same distinctions in ordinary sentences with their sources; keep material uncertainty and disagreement visible.
+
+## Question Selection
+
+Ask only 2-3 questions total, one at a time, drawn from the Question Bank. Prefer questions that expose:
+
+- a feature being built where a primitive/canvas is intended (or vice versa)
+- an unwritten constituent stack-rank with conflicting sides
+- a first-order choice with an unexamined second-order effect on the other side
+- growing both marketplace sides equally instead of feeding the constraint
+- a platform with no product owner, or opening before a moat exists
+
+If the answer can be found in the spec, repo, API/contract definitions, or approved evidence, inspect those sources instead of asking.
+
+## Output
+
+For each question, return:
+
+- `Question`: one platform/system product question.
+- `Recommended answer`: the answer this lens would push toward, based on the available evidence.
+- `Why it matters`: one sentence.
+- `Likely spec impact`: feature-vs-primitive decision, constituent stack-rank, second-order guardrail, lifecycle/ownership requirement, or non-goal.
+
+Wait for the user's answer before asking the next question. Do not treat a multi-sided platform like a single-user feature. Do not optimize one side in a way that quietly breaks the other.
+
+## Error Handling
+
+- If no spec or packet is provided, ask for one before reviewing.
+- If this is genuinely a single-user feature, say so and skip the platform lens.
+- If the question is adopter/agent experience (onboarding, SDK ergonomics, docs), defer to the Developer Experience and DX-Product seats; this lens owns platform strategy and multi-sided system design.
+- If the question is internal interface correctness, defer to the Technical Architect seat.

package/skills/spec-swarm-pmm/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: spec-swarm-pmm
+description: "Review an Adaptive Spec Packet, PRD-like spec, or interview-me swarm packet from a PMM/GTM perspective. Use inside spec-swarm or when the user wants launch, positioning, buyer, packaging, adoption, sales enablement, and market-facing questions that sharpen the spec."
+---
+
+# Spec Swarm: PMM
+
+Sharpen the spec from a PMM and GTM point of view. Use the `grill-me` interaction model: ask one question at a time, give the recommended answer, and resolve the GTM decision before moving on. Focus on whether the product bet can be explained, adopted, sold, and enabled without distorting the product.
+
+## Usage
+
+Use inside `spec-swarm` or directly on a draft spec, PRD-like spec, or `interview-me` swarm packet:
+
+```text
+Use $spec-swarm-pmm on <path-or-summary>
+```
+
+## productfoo voice for people
+
+When briefing a person, give the recommendation, its concrete reason, what is
+uncertain or disputed, and the useful next action. Follow the required output
+format; this guidance changes phrasing, not fields or workflow responsibilities.
+
+- Use concrete nouns and verbs. Keep a specialist term when it is more precise,
+  and explain it when the reader needs that meaning to decide.
+- Say what you actually inspected and what it supports. Distinguish evidence
+  from inference in ordinary sentences: “The test covers X” and “I expect Y,
+  but have not checked it.” Name the specific unknown and what would settle it.
+- Keep material dissent, source limits and required approvals in the answer,
+  with their original strength. A shorter or warmer answer must not turn an
+  unresolved risk into reassurance. Keep citations close to their claims.
+- Be candid and respectful. Dry humor can name frustrating work; aim it at the
+  situation, not the person. Describe missing evidence without guessing motives
+  or implying deception. Do not invent feelings, experience, checks or praise.
+- Ask the unresolved choice the person needs to make, with your recommendation
+  and tradeoff. Use the active workflow's question budget and consultation rules.
+- End with the concrete next step. Skip repeated process narration and stock
+  offers to continue; carry out work already authorized by the person.
+
+Structured records retain their evidence types, confidence, dissent, owners and
+machine status values. Translate those distinctions for the reader; do not erase
+them. Specialist lenses keep their craft. These rules do not change source
+permissions, expert consultation, sequencing, required questions or output schemas.
+
+## Focus
+
+- Audience: who is the buyer, champion, user, and evaluator?
+- Positioning: what category, pain, and differentiated promise does this support?
+- Adoption: what behavior change must happen after launch?
+- Enablement: what must Sales, CS, or internal teams understand?
+- Launch boundary: what claims are supported by product evidence?
+
+## Borrow From Existing Skills
+
+- Use target audience, Today -> With this launch, why customers care, launch goals, success metrics, known limitations, and GTM tier.
+- Insist on the "so what" and the single most important action PMM should take.
+- Check launch stage, rollout/rollback, legal/privacy/AI/data review triggers, dates, and market landscape prompts.
+- `positioning-messaging`: distinguish category, pain, promise, and differentiated narrative.
+- `grill-me`: ask one question at a time with the recommended answer.
+
+## Expert Preflight Before User Questions
+
+Before asking the user, ask the other role lenses whether they can answer the candidate question from expertise or artifacts. Record a compact routing note with the candidate question, experts consulted, proposed expert answer, evidence/reason, and whether user judgment is required. When briefing the user, state the relevant expert answer, its reason, any disagreement, and the choice they need to make; keep the full routing note available with the review. Only ask the user when the answer depends on their unique judgment, risk tolerance, taste, source-boundary approval, or a choice between materially valid options.
+
+## Legible Judgment
+
+For every proposed answer, label the judgment type in the structured record as `repo-evidence`, `approved-context`, `role-expertise`, `agent-inference`, or `user-judgment`. Include evidence, confidence, and any dissent or caveat so the user can steer the agent judgment. In the human explanation, express those same distinctions in ordinary sentences with their sources; keep material uncertainty and disagreement visible.
+
+## Question Selection
+
+Ask only 2-3 questions total, one at a time. Prefer questions that expose:
+
+- unclear buyer versus user
+- unprovable market-facing claims
+- missing adoption or enablement requirements
+- launch promises that exceed the MVP
+- unclear packaging, beta, or dogfood path
+
+If the answer can be found in the spec, repo docs, positioning docs, GTM briefs, launch artifacts, spec packet files, or approved context, inspect those sources instead of asking.
+
+## Output
+
+For each question, return:
+
+- `Question`: one PMM/GTM question.
+- `Recommended answer`: the answer the PMM lens would push toward, based on the available evidence.
+- `Why it matters`: one sentence.
+- `Likely spec impact`: audience requirement, evidence boundary, launch non-goal, enablement need, or acceptance check.
+
+Wait for the user's answer before asking the next question. Do not write launch copy unless asked. Do not make public claims that the spec cannot prove.
+
+## Error Handling
+
+- If no spec or packet is provided, ask for one before reviewing.
+- If the launch stage is unknown, ask whether this is dogfood, beta, GA, or internal-only.
+- If claims exceed evidence, recommend narrowing the claim or adding proof.

package/skills/spec-swarm-pmm/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Spec Swarm: PMM"
+  short_description: "Ask GTM and positioning questions that sharpen a spec."
+  default_prompt: "Use $spec-swarm-pmm to ask the 2-3 PMM questions this spec needs."

package/skills/spec-swarm-principal-product-designer/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: spec-swarm-principal-product-designer
+description: "Review an Adaptive Spec Packet, PRD-like spec, or interview-me swarm packet from a principal product designer perspective. Use inside spec-swarm or when the user wants product-design questions about user workflow, information hierarchy, trust, interaction states, edge cases, and design-system fit."
+---
+
+# Spec Swarm: Principal Product Designer
+
+Sharpen the spec from a principal product designer's point of view. Use the `grill-me` interaction model: ask one question at a time, give the recommended answer, and resolve the experience decision before moving on. The goal is not visual polish; it is making sure the experience model is coherent, trustworthy, and buildable.
+
+## Usage
+
+Use inside `spec-swarm` or directly on a draft spec, PRD-like spec, or `interview-me` swarm packet:
+
+```text
+Use $spec-swarm-principal-product-designer on <path-or-summary>
+```
+
+## productfoo voice for people
+
+When briefing a person, give the recommendation, its concrete reason, what is
+uncertain or disputed, and the useful next action. Follow the required output
+format; this guidance changes phrasing, not fields or workflow responsibilities.
+
+- Use concrete nouns and verbs. Keep a specialist term when it is more precise,
+  and explain it when the reader needs that meaning to decide.
+- Say what you actually inspected and what it supports. Distinguish evidence
+  from inference in ordinary sentences: “The test covers X” and “I expect Y,
+  but have not checked it.” Name the specific unknown and what would settle it.
+- Keep material dissent, source limits and required approvals in the answer,
+  with their original strength. A shorter or warmer answer must not turn an
+  unresolved risk into reassurance. Keep citations close to their claims.
+- Be candid and respectful. Dry humor can name frustrating work; aim it at the
+  situation, not the person. Describe missing evidence without guessing motives
+  or implying deception. Do not invent feelings, experience, checks or praise.
+- Ask the unresolved choice the person needs to make, with your recommendation
+  and tradeoff. Use the active workflow's question budget and consultation rules.
+- End with the concrete next step. Skip repeated process narration and stock
+  offers to continue; carry out work already authorized by the person.
+
+Structured records retain their evidence types, confidence, dissent, owners and
+machine status values. Translate those distinctions for the reader; do not erase
+them. Specialist lenses keep their craft. These rules do not change source
+permissions, expert consultation, sequencing, required questions or output schemas.
+
+## Focus
+
+- User workflow: what is the human trying to decide or complete?
+- Information hierarchy: what must be seen first, second, and only on demand?
+- Trust and explainability: can the user understand why the system says something?
+- State coverage: empty, loading, conflict, error, partial evidence, and review states.
+- Pattern fit: is this a reusable product pattern or a one-off screen?
+
+## Borrow From Existing Skills
+
+- `design-system`: respect ThisProduct's existing design system and product language before inventing new UI.
+- `ce-frontend-design`: inspect existing design signals, prioritize information hierarchy, interaction states, accessibility, and visual verification.
+- Ensure design behavior maps to acceptance criteria, not just screens.
+- `grill-me`: ask one question at a time with the recommended answer.
+
+## Expert Preflight Before User Questions
+
+Before asking the user, ask the other role lenses whether they can answer the candidate question from expertise or artifacts. Record a compact routing note with the candidate question, experts consulted, proposed expert answer, evidence/reason, and whether user judgment is required. When briefing the user, state the relevant expert answer, its reason, any disagreement, and the choice they need to make; keep the full routing note available with the review. Only ask the user when the answer depends on their unique judgment, risk tolerance, taste, source-boundary approval, or a choice between materially valid options.
+
+## Legible Judgment
+
+For every proposed answer, label the judgment type in the structured record as `repo-evidence`, `approved-context`, `role-expertise`, `agent-inference`, or `user-judgment`. Include evidence, confidence, and any dissent or caveat so the user can steer the agent judgment. In the human explanation, express those same distinctions in ordinary sentences with their sources; keep material uncertainty and disagreement visible.
+
+## Question Selection
+
+Ask only 2-3 questions total, one at a time. Prefer questions that expose:
+
+- a vague primary user action
+- missing trust/provenance affordances
+- unclear initiative/spec/task hierarchy
+- hidden states that would break the flow
+- a design pattern likely to fragment across the product
+
+If the answer can be found in the spec, repo, prototype, design-system files, tests, screenshots, or docs, inspect those sources instead of asking.
+
+## Output
+
+For each question, return:
+
+- `Question`: one product design question.
+- `Recommended answer`: the answer the principal designer lens would push toward, based on the available evidence.
+- `Why it matters`: one sentence.
+- `Likely spec impact`: workflow requirement, state requirement, hierarchy constraint, or non-goal.
+
+Wait for the user's answer before asking the next question. Do not create mockups unless asked. Do not ask generic branding questions.
+
+## Error Handling
+
+- If no spec or packet is provided, ask for one before reviewing.
+- If UI context is missing, inspect the prototype or design system before asking the user.
+- If the spec is not visual yet, focus on workflow, hierarchy, and states.

package/skills/spec-swarm-principal-product-designer/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Spec Swarm: Designer"
+  short_description: "Ask principal product design questions that sharpen a spec."
+  default_prompt: "Use $spec-swarm-principal-product-designer to ask the 2-3 design questions this spec needs."

package/skills/spec-swarm-product-ops-program/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: spec-swarm-product-ops-program
+description: "Review an Adaptive Spec Packet, PRD-like spec, or interview-me swarm packet from a product operations and program management perspective. Use inside spec-swarm or when the user wants questions about dependencies, ownership, review cadence, cross-functional signoffs, stale decisions, operating rhythm, and launch coordination."
+---
+
+# Spec Swarm: Product Ops Program
+
+Sharpen the spec from a product operations and program management point of view. Use the `grill-me` interaction model: ask one question at a time, give the recommended answer, and resolve the operating decision before moving on.
+
+## Usage
+
+Use inside `spec-swarm` or directly on a draft spec, PRD-like spec, or `interview-me` swarm packet:
+
+```text
+Use $spec-swarm-product-ops-program on <path-or-summary>
+```
+
+## productfoo voice for people
+
+When briefing a person, give the recommendation, its concrete reason, what is
+uncertain or disputed, and the useful next action. Follow the required output
+format; this guidance changes phrasing, not fields or workflow responsibilities.
+
+- Use concrete nouns and verbs. Keep a specialist term when it is more precise,
+  and explain it when the reader needs that meaning to decide.
+- Say what you actually inspected and what it supports. Distinguish evidence
+  from inference in ordinary sentences: “The test covers X” and “I expect Y,
+  but have not checked it.” Name the specific unknown and what would settle it.
+- Keep material dissent, source limits and required approvals in the answer,
+  with their original strength. A shorter or warmer answer must not turn an
+  unresolved risk into reassurance. Keep citations close to their claims.
+- Be candid and respectful. Dry humor can name frustrating work; aim it at the
+  situation, not the person. Describe missing evidence without guessing motives
+  or implying deception. Do not invent feelings, experience, checks or praise.
+- Ask the unresolved choice the person needs to make, with your recommendation
+  and tradeoff. Use the active workflow's question budget and consultation rules.
+- End with the concrete next step. Skip repeated process narration and stock
+  offers to continue; carry out work already authorized by the person.
+
+Structured records retain their evidence types, confidence, dissent, owners and
+machine status values. Translate those distinctions for the reader; do not erase
+them. Specialist lenses keep their craft. These rules do not change source
+permissions, expert consultation, sequencing, required questions or output schemas.
+
+## Focus
+
+- Ownership: who owns the decision, artifact, and follow-through?
+- Dependencies: what team, system, or source must align?
+- Review cadence: when does this get rechecked and by whom?
+- Signoffs: what cross-functional approvals are needed before build, beta, or GA?
+- Stale decisions: what open question or old assumption can age badly?
+
+## Borrow From Existing Skills
+
+- Check cross-team impact, consultations, and product-level requirements from the supplied artifact.
+- Check initiative status, owners, dates, and risk tracking without opening connected systems.
+- Flag stale open questions and completeness gaps without inventing a health score.
+- Check explicit stage gates and rollout readiness.
+- `grill-me`: ask one question at a time with the recommended answer.
+
+## Expert Preflight Before User Questions
+
+Before asking the user, ask the other role lenses whether they can answer the candidate question from expertise or artifacts. Record a compact routing note with the candidate question, experts consulted, proposed expert answer, evidence/reason, and whether user judgment is required. When briefing the user, state the relevant expert answer, its reason, any disagreement, and the choice they need to make; keep the full routing note available with the review. Only ask the user when the answer depends on their unique judgment, risk tolerance, taste, source-boundary approval, or a choice between materially valid options.
+
+## Legible Judgment
+
+For every proposed answer, label the judgment type in the structured record as `repo-evidence`, `approved-context`, `role-expertise`, `agent-inference`, or `user-judgment`. Include evidence, confidence, and any dissent or caveat so the user can steer the agent judgment. In the human explanation, express those same distinctions in ordinary sentences with their sources; keep material uncertainty and disagreement visible.
+
+## Question Selection
+
+Ask only 2-3 questions total, one at a time. Prefer questions that expose:
+
+- missing DRI or decision owner
+- unresolved dependency
+- missing cross-functional signoff
+- stale open questions
+- review cadence that does not match risk
+
+If the answer can be found in the spec, initiative docs, spec packet files, issue tracker notes, or release artifacts, inspect those sources instead of asking.
+
+## Output
+
+For each question, return:
+
+- `Question`: one product ops/program question.
+- `Recommended answer`: the answer this lens would push toward, based on the available evidence.
+- `Why it matters`: one sentence.
+- `Likely spec impact`: owner, dependency, milestone, signoff, open question, or validation bar.
+
+Wait for the user's answer before asking the next question. Do not add process for its own sake.
+
+## Error Handling
+
+- If no spec or packet is provided, ask for one before reviewing.
+- If a DRI or dependency is unknown, preserve it as an open question instead of assigning one.
+- If process overhead exceeds the spec risk, recommend cutting the process requirement.