productfoo 0.0.0-stage → 1.0.1

package/skills/spec-swarm-product-ops-program/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Spec Swarm: Product Ops"
+  short_description: "Ask operating and dependency questions that sharpen a spec."
+  default_prompt: "Use $spec-swarm-product-ops-program to ask the 2-3 product ops/program questions this spec needs."

package/skills/spec-swarm-qa-release/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: spec-swarm-qa-release
+description: "Review an Adaptive Spec Packet, PRD-like spec, or interview-me swarm packet from a QA and release perspective. Use inside spec-swarm or when the user wants questions about acceptance coverage, rollout and rollback, beta or GA blockers, regression risk, bug bash scope, and release readiness."
+---
+
+# Spec Swarm: QA Release
+
+Sharpen the spec from a QA and release readiness point of view. Use the `grill-me` interaction model: ask one question at a time, give the recommended answer, and resolve the release-risk 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-qa-release 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
+
+- Acceptance coverage: what user-visible behavior must be tested?
+- Rollout and rollback: how does this fail safely?
+- Release gates: what would block beta or GA?
+- Regression risk: what existing flows, data, or old prototype access can break?
+- Bug bash scope: what states and edge cases deserve focused testing?
+
+## Borrow From Existing Skills
+
+- Check build/beta/GA readiness, rollout/rollback, and legal review prompts.
+- `ce-code-review`: severity, reliability, API contract, security, migration, and testing instincts.
+- `ce-doc-review`: feasibility, scope, and document quality checks.
+- Check acceptance-criteria quality directly from the supplied artifact.
+- `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:
+
+- acceptance criteria that cannot be verified
+- missing rollback or preservation requirements
+- beta/GA blockers
+- high-risk regression paths
+- untested edge states
+
+If the answer can be found in the spec, repo, tests, release checklist, spec packet files, or prototype docs, inspect those sources instead of asking.
+
+## Output
+
+For each question, return:
+
+- `Question`: one QA/release question.
+- `Recommended answer`: the answer this lens would push toward, based on the available evidence.
+- `Why it matters`: one sentence.
+- `Likely spec impact`: acceptance check, release gate, rollout requirement, rollback requirement, or non-goal.
+
+Wait for the user's answer before asking the next question. Do not claim release readiness without runnable verification evidence.
+
+## Error Handling
+
+- If no spec or packet is provided, ask for one before reviewing.
+- If no runnable verification exists, mark the release bar as not yet met.
+- If beta or GA criteria are missing, ask for the release stage before evaluating readiness.

package/skills/spec-swarm-qa-release/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Spec Swarm: QA Release"
+  short_description: "Ask QA and release readiness questions that sharpen a spec."
+  default_prompt: "Use $spec-swarm-qa-release to ask the 2-3 QA/release questions this spec needs."

package/skills/spec-swarm-responsible-ai-safety/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: spec-swarm-responsible-ai-safety
+description: "Review an Adaptive Spec Packet, PRD-like spec, or interview-me swarm packet from a responsible-AI and agent trust & safety perspective. Use inside spec-swarm or when the user wants questions about prompt injection, the lethal trifecta, excessive agency, irreversible or outbound actions, exfiltration channels, capability scoping, and goal-hijack of an autonomous or delegated agent."
+---
+
+# Spec Swarm: Responsible-AI & Agent Trust & Safety
+
+Sharpen the spec from a responsible-AI and agent trust & safety point of view. Use the `grill-me` interaction model: ask one question at a time, give the recommended answer, and resolve the safety decision before moving on. This lens treats the agent itself as the attack surface and "authorized-but-harmful" as the central failure class: the agent uses its legitimate permissions to do damage because untrusted input hijacked its goal. It assumes the system can be turned against its own design through its own inputs, even while every action remains technically authorized.
+
+## Usage
+
+Use inside `spec-swarm` or directly on a draft spec, PRD-like spec, or `interview-me` swarm packet:
+
+```text
+Use $spec-swarm-responsible-ai-safety 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
+
+- The lethal trifecta: does the agent hold private data, exposure to untrusted content, and an external-communication path at the same time?
+- Excessive agency: tool blast radius, least privilege, and whose authority the agent carries when it acts (confused deputy).
+- Irreversible and outbound actions: is a human approval interposed before each send, delete, pay, deploy, push, or grant?
+- Untrusted input and exfiltration: where indirect prompt injection enters, and every channel that can leak context back out.
+- Behavioral safety: goal-hijack vs honest pursuit, behavior under goal pressure, and whether the defense is architectural or merely probabilistic.
+
+## Grounding
+
+This lens carries the working judgment of the practitioners and standards that define agent security. Use their reflexes as question sources:
+
+- Simon Willison — the lethal trifecta (private data + untrusted content + exfiltration path), prompt injection vs jailbreaking, the dual LLM pattern, and "in application security, 99% is a failing grade" (remove a capability, do not filter the attack).
+- Johann Rehberger — the AI kill chain (injection → confused deputy → automatic tool invocation), exfiltration channels (markdown images, links, unfurling), ASCII smuggling, memory poisoning, MCP tool poisoning.
+- Anthropic — agentic misalignment / insider-threat framing, behavior under goal pressure, "naïve direct behavioral instruction was not sufficient," human approval for irreversible actions, and evaluation-vs-deployment behavior gaps.
+- OWASP Gen AI — LLM01 Prompt Injection, LLM05 Improper Output Handling, LLM06 Excessive Agency, and the Agentic Top 10 (ASI01 Goal Hijack, ASI03 Identity/Privilege Abuse, ASI06 Memory Poisoning).
+- Rich Harang / NVIDIA — "control and data planes are not separable," risk lives in the tools not the autonomy level, treat all model output as untrusted, sandbox execution and block egress.
+- Bruce Schneier — LLMs have no separation of data and control (in-band signaling); prompt injection is structural, fix it with security engineering, not self-policing.
+- Lakera — guard on both sides (input guard plus output guard); keyword blacklists fail.
+
+Also enforce productfoo's own boundaries: B1 (never commit raw private source material) and B4 (any loop or autonomous action needs a valid loop contract). Check explicit release-review triggers directly from the supplied artifact.
+
+## Question Bank
+
+Draw the swarm's questions from this ranked bank; each forces a decision, exposes risk, or improves validation.
+
+1. Does this agent hold all three legs of the lethal trifecta — private/sensitive data, exposure to untrusted content, and an external-communication path? If yes, which leg does the spec cut? No prompt fixes a system that holds all three.
+2. Enumerate every exfiltration channel the agent can reach (rendered images, hyperlinks, mailto, link unfurling, DNS, network-calling code, allow-listed domains). Which are removed, and which remain as accepted risk?
+3. Once untrusted content enters context, can the agent still trigger a consequential or irreversible action without out-of-band human approval? Name each irreversible/outbound action and its gate.
+4. Where does untrusted or external content enter — retrieval, web fetch, file or email contents, tool outputs, sub-agent messages, tool descriptions, long-term memory — and how is indirect prompt injection contained on each channel?
+5. What is the agent's tool blast radius, and is it least-privilege? Justify why each sensitive tool must be reachable from an untrusted-input path. Risk lives in the tools, not the autonomy level.
+6. Whose authority does the agent carry when it acts (confused-deputy check)? Can a poisoned document make it exercise permissions the human requester does not hold?
+7. Goal-hijack vs honest pursuit: at runtime, how do we distinguish an agent corrupted into the attacker's goal from one faithfully pursuing the user's? What trace reveals it acted on injected instructions?
+8. Under goal pressure — shutdown, replacement, a blocked path — what is the worst action the agent's tools and access permit, and has that cornered scenario been tested, not just the happy path?
+9. Is any model output passed to an interpreter, shell, SQL engine, browser, or another agent without validation or encoding for that sink?
+10. Can an injection reach persistent state — memory, files, repos, config or hooks or settings — and survive across sessions or propagate to other agents (wormability)? Who reviews stored memory?
+11. Is risky execution sandboxed — egress blocked, writes confined, config and hook writes denied — and are human approvals never cached across actions?
+12. Is the defense architectural or probabilistic? If it depends on a classifier or filter, what is the residual failure rate, and is that acceptable for a security boundary ("99% is a failing grade")?
+
+## 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:
+
+- the lethal trifecta assembled in one agent context
+- an irreversible or outbound action with no human gate
+- an untrusted-input channel with an unbroken path to a sensitive tool
+- a defense that is a probabilistic filter mistaken for a security boundary
+- goal-hijack that would be indistinguishable from honest pursuit at runtime
+
+If the answer can be found in the spec, repo, loop contract, tool definitions, source map, or approved evidence, inspect those sources instead of asking.
+
+## Output
+
+For each question, return:
+
+- `Question`: one responsible-AI / trust & safety question.
+- `Recommended answer`: the answer this lens would push toward, based on the available evidence.
+- `Why it matters`: one sentence.
+- `Likely spec impact`: requirement, must-not, capability scope, approval gate, terminal state, or validation bar.
+
+Wait for the user's answer before asking the next question. Do not ask for secrets, credentials, or raw private content. Do not accept a probabilistic filter as a security boundary. Do not clear a risk by assuming a system-prompt prohibition holds under pressure.
+
+## Error Handling
+
+- If no spec or packet is provided, ask for one before reviewing.
+- If the spec describes an autonomous or delegated agent without a loop contract, route to B4 before clearing safety.
+- If a safety control is unknown, mark it as a review trigger rather than clearing the risk.
+- If review would require credentials, secrets, or raw private content, refuse that input path and ask for a redacted summary.

package/skills/spec-swarm-security-privacy-legal/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: spec-swarm-security-privacy-legal
+description: "Review an Adaptive Spec Packet, PRD-like spec, or interview-me swarm packet from a security, privacy, and legal perspective. Use inside spec-swarm or when the user wants questions about data handling, AI/legal review triggers, private evidence boundaries, consent, access, compliance, and risk controls."
+---
+
+# Spec Swarm: Security Privacy Legal
+
+Sharpen the spec from a security, privacy, and legal point of view. Use the `grill-me` interaction model: ask one question at a time, give the recommended answer, and resolve the risk 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-security-privacy-legal 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
+
+- Data handling: what new data is collected, inferred, stored, shared, or exposed?
+- AI/legal triggers: does automated reasoning affect content, access, recommendations, or user-visible claims?
+- Private evidence: what must remain context-only versus canonical spec evidence?
+- Consent and access: who can see, approve, redact, or revoke source material?
+- Compliance and recovery: what failure mode requires review, auditability, or rollback?
+
+## Borrow From Existing Skills
+
+- Check legal review triggers for data, AI, vendors, permissions, monetization, and market changes.
+- Enforce sensitive-source hygiene without reading or rewriting raw transcripts.
+- `privacy-source-interview`: privacy ladders, high-risk defaults, and source maps.
+- `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:
+
+- hidden data collection or inference
+- raw private evidence entering canonical artifacts
+- vendor or cloud-model exposure
+- missing consent, access, or audit boundary
+- legal/review triggers that change release readiness
+
+If the answer can be found in the spec, repo, source map, privacy notes, release checklist, or approved evidence, inspect those sources instead of asking.
+
+## Output
+
+For each question, return:
+
+- `Question`: one security/privacy/legal question.
+- `Recommended answer`: the answer this lens would push toward, based on the available evidence.
+- `Why it matters`: one sentence.
+- `Likely spec impact`: requirement, must-not, evidence boundary, approval gate, or validation bar.
+
+Wait for the user's answer before asking the next question. Do not ask for secrets, credentials, or raw private content.
+
+## Error Handling
+
+- If no spec or packet is provided, ask for one before reviewing.
+- If legal or privacy facts are unknown, mark them as review triggers rather than clearing the risk.
+- If the review would require credentials, secrets, or raw private content, refuse that input path and ask for a redacted summary.

package/skills/spec-swarm-security-privacy-legal/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Spec Swarm: Sec/Privacy/Legal"
+  short_description: "Ask security, privacy, and legal questions that sharpen a spec."
+  default_prompt: "Use $spec-swarm-security-privacy-legal to ask the 2-3 security/privacy/legal questions this spec needs."

package/skills/spec-swarm-strategy-competitive/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: spec-swarm-strategy-competitive
+description: "Review an Adaptive Spec Packet, PRD-like spec, or interview-me swarm packet from a strategy and competitive perspective. Use inside spec-swarm or when the user wants questions about why now, why us, alternatives, durable differentiation, strategic alignment, market category, and strategic drift."
+---
+
+# Spec Swarm: Strategy Competitive
+
+Sharpen the spec from a strategy and competitive point of view. Use the `grill-me` interaction model: ask one question at a time, give the recommended answer, and resolve the strategic 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-strategy-competitive 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
+
+- Why now: what makes this newly urgent or newly possible?
+- Why us: what advantage does ThisProduct have here?
+- Alternatives: what existing tool, process, or competitor would customers use instead?
+- Differentiation: what should be durable versus demo-only?
+- Strategic alignment: does this reinforce the product thesis or create drift?
+
+## Borrow From Existing Skills
+
+- `strategy-check`: strategy alignment and drift.
+- Test competitors, alternatives, objections, and differentiation using only approved evidence in the supplied artifact.
+- `cpo-lens`: strategic reframing, stack ranking, revenue instinct, and future-state thinking.
+- `positioning-messaging`: category and narrative clarity.
+- `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:
+
+- weak urgency
+- fuzzy category or alternative set
+- feature work that does not support the thesis
+- differentiation that is actually table stakes
+- a strategic bet hidden as a small UI change
+
+If the answer can be found in the spec, strategy docs, positioning docs, competitive notes, or repo thesis docs, inspect those sources instead of asking.
+
+## Output
+
+For each question, return:
+
+- `Question`: one strategy/competitive question.
+- `Recommended answer`: the answer this lens would push toward, based on the available evidence.
+- `Why it matters`: one sentence.
+- `Likely spec impact`: problem framing, non-goal, positioning constraint, priority change, or validation bar.
+
+Wait for the user's answer before asking the next question. Do not turn the spec into a market memo unless the user chooses that path.
+
+## Error Handling
+
+- If no spec or packet is provided, ask for one before reviewing.
+- If competitive facts may be current or time-sensitive, verify them before treating them as evidence.
+- If strategy docs are missing, label strategy alignment as an inference, not a confirmed fact.

package/skills/spec-swarm-strategy-competitive/agents/openai.yaml

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

package/skills/spec-swarm-technical-architect/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: spec-swarm-technical-architect
+description: "Review an Adaptive Spec Packet, PRD-like spec, or interview-me swarm packet from a technical architect perspective. Use inside spec-swarm or when the user wants architecture questions about boundaries, data contracts, source authority, integrations, extensibility, and future-system fit."
+---
+
+# Spec Swarm: Technical Architect
+
+Sharpen the spec from the system architecture point of view. Use the `grill-me` interaction model: ask one question at a time, give the recommended answer, and resolve the architectural decision before moving on. Focus on boundaries, data contracts, and long-term coherence before implementation planning begins.
+
+## Usage
+
+Use inside `spec-swarm` or directly on a draft spec, PRD-like spec, or `interview-me` swarm packet:
+
+```text
+Use $spec-swarm-technical-architect 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
+
+- System boundary: what owns the behavior, data, and source authority?
+- Data model: what are the durable objects, IDs, states, and provenance links?
+- Integration shape: what is source-agnostic now versus connector-specific later?
+- Extensibility: what must remain stable as more sources, agents, and reviewers appear?
+- Failure modes: what happens when evidence conflicts, disappears, or is private?
+
+## Borrow From Existing Skills
+
+- `ce-plan`: separate decisions from code; identify boundaries, files, dependencies, risks, and test scenarios without pre-writing implementation.
+- `ce-agent-native-architecture`: check parity, primitive tools versus workflow tools, shared workspace assumptions, context limits, and completion signals when agentic behavior is involved.
+- Surface non-obvious cross-team/system impact and convert ambiguity into product-level requirements.
+- `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:
+
+- duplicated ownership across specs or services
+- missing canonical IDs or source-provenance contracts
+- hidden coupling to a vendor, connector, or prototype fixture
+- unclear lifecycle state transitions
+- architectural choices disguised as UI requirements
+
+If the answer can be found in the spec, repo, spec packet files, source code, tests, scripts, or docs, inspect those sources instead of asking.
+
+## Output
+
+For each question, return:
+
+- `Question`: one architecture question.
+- `Recommended answer`: the answer the architect lens would push toward, based on the available evidence.
+- `Why it matters`: one sentence.
+- `Likely spec impact`: owner change, data contract, integration boundary, requirement, or non-goal.
+
+Wait for the user's answer before asking the next question. Do not propose a full architecture unless asked. Do not overfit to current implementation details.
+
+## Error Handling
+
+- If no spec or packet is provided, ask for one before reviewing.
+- If ownership is ambiguous, ask which capability owns the behavior before proposing architecture.
+- If implementation details are missing, ask only for decisions that change the spec boundary.

package/skills/spec-swarm-technical-architect/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Spec Swarm: Architect"
+  short_description: "Ask architecture questions that sharpen a spec."
+  default_prompt: "Use $spec-swarm-technical-architect to ask the 2-3 architecture questions this spec needs."

package/skills/spec-swarm-technical-lead/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: spec-swarm-technical-lead
+description: "Review an Adaptive Spec Packet, PRD-like spec, or interview-me swarm packet from a technical lead perspective. Use inside spec-swarm or when the user wants engineering execution questions about buildability, sequencing, tests, operational risk, and implementation slices."
+---
+
+# Spec Swarm: Technical Lead
+
+Sharpen the spec from an engineering execution point of view. Use the `grill-me` interaction model: ask one question at a time, give the recommended answer, and resolve the buildability decision before moving on. Focus on sequencing and verification without turning the spec into an implementation plan.
+
+## Usage
+
+Use inside `spec-swarm` or directly on a draft spec, PRD-like spec, or `interview-me` swarm packet:
+
+```text
+Use $spec-swarm-technical-lead 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
+
+- Build slice: what can be implemented and verified first?
+- Testability: what tests or checks prove the behavior?
+- Dependencies: what existing code, data, services, or workflows must change?
+- Operational risk: what can break for existing users or the old prototype?
+- Edge cases: what inputs, states, or permissions make the work fragile?
+
+## Borrow From Existing Skills
+
+- `ce-work`: translate approved scope into a buildable sequence, but do not start implementation during the swarm.
+- `ce-code-review`: use severity thinking, test gaps, reliability, API contract, migration, security, and performance instincts.
+- `ce-doc-review`: classify whether the artifact is requirements or implementation planning; challenge feasibility and scope accordingly.
+- Make acceptance examples testable and grammatically clean.
+- `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:
+
+- requirements that cannot be tested
+- missing migration or preservation work
+- unclear sequencing across UI, data, and spec artifacts
+- hidden dependency on unavailable services
+- a "done" definition without runnable verification
+
+If the answer can be found in the spec, repo, source code, tests, package scripts, spec packet files, or docs, inspect those sources instead of asking.
+
+## Output
+
+For each question, return:
+
+- `Question`: one technical lead question.
+- `Recommended answer`: the answer the technical lead lens would push toward, based on the available evidence.
+- `Why it matters`: one sentence.
+- `Likely spec impact`: acceptance check, task boundary, dependency, non-goal, or validation bar.
+
+Wait for the user's answer before asking the next question. Do not estimate unless asked. Do not turn the response into a task breakdown unless the spec is already approved.
+
+## Error Handling
+
+- If no spec or packet is provided, ask for one before reviewing.
+- If verification is impossible from the current repo, mark that as a spec risk.
+- If the request becomes implementation planning, hand off to `ce-plan` or `ce-work`.

package/skills/spec-swarm-technical-lead/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Spec Swarm: Tech Lead"
+  short_description: "Ask engineering execution questions that sharpen a spec."
+  default_prompt: "Use $spec-swarm-technical-lead to ask the 2-3 technical lead questions this spec needs."